Re: [alsa-devel] [PATCH v2 3/3] ASoC: add generic dt-card support
On Fri, 23 Jan 2015 19:13:43 + Mark Brown wrote: > On Fri, Jan 23, 2015 at 07:34:56PM +0100, Jean-Francois Moine wrote: > > > A card builder is a device which > > - scans the graph of ports, > > - fills the struct snd_soc_card according to the links between the > > ports and their properties, > > - and, eventually, calls snd_soc_register_card(). > > > The simple card builder, 'dt-card' (maybe a better name would have been > > 'graph-card'), acts just like the simple-card except that it does not > > appear in the DT. Its creation is done by an audio controller. > > Which audio controller? There may be several CPU side audio interfaces > in the same card. For example people often want to have both low > latency and high latency audio paths from the CPU into the hardware (low > latency tends to increase power burn). SoC centric system designs do > sometimes also have PDM I/O, expecting to be directly connected to DMICs > and so on, which results in a relatively large number of CPU interfaces. The audio controller which creates the card depends on the complexity of the card. When there are many controllers, it is up to the designer to define either a master audio controller or to instantiate a 'card' device via the DT for doing the job. > > > > With a DT graph, each CPU/CODEC would know exactly the widgets and > > > > routes it has to define. > > > > Which widgets/routes do you mean? > > > Well, forget about this. I never clearly understood why some widgets > > and routes had to be defined at card level. > > Please do try to understand the idea of representing simple components > on the board and analogue interconects between devices - it's really > important and not something that can be neglected. The problem is that this understanding would stay abstract: I have no such a hardware. Anyway, if the representation can be done with the simple-card, it may also be done with a graph of ports. > > > I'd agree if this was some kind of kernel internal stuff, but this is > > > creating ABI and we have to maintain it forever. Rushing this in without > > > proper discussion and consideration of the more complex use-cases is in > > > my > > > opinion not a good idea. > > > Using a graph of port to describe the audio subsystem has been pushed > > forwards by many people for a long time, as shown by the creation of > > the document Documentation/devicetree/bindings/graph.txt. > > That DT binding was done entirely in the context of video applications > IIRC, this is the first time it's been discussed in this context. http://mailman.alsa-project.org/pipermail/alsa-devel/2014-January/070622.html http://mailman.alsa-project.org/pipermail/alsa-devel/2015-January/086273.html -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: mmotm 2015-01-22-15-04: qemu failure due to 'mm: memcontrol: remove unnecessary soft limit tree node test'
On Fri, Jan 23, 2015 at 03:09:20PM -0600, Christoph Lameter wrote: > On Fri, 23 Jan 2015, Guenter Roeck wrote: > > > Wouldn't that have unintended consequences ? So far > > rb tree nodes are allocated even if a node not online; > > the above would change that. Are you saying it is > > unnecessary to initialize rb tree nodes if the node > > is not online ? > > It is not advisable to allocate since an offline node means that the > structure cannot be allocated on the node where it would be most > beneficial. Typically subsystems allocate the per node data structures > when the node is brought online. I would generally agree, but this code, which implements a userspace interface, is already grotesquely inefficient and heavyhanded. It's also superseded in the next release, so we can just keep this simple at this point. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
mmotm 2015-01-23-16-19: build failures due to 'mm/page_alloc.c: don't offset memmap for flatmem'
On Fri, Jan 23, 2015 at 04:19:40PM -0800, a...@linux-foundation.org wrote:
> The mm-of-the-moment snapshot 2015-01-23-16-19 has been uploaded to
>
>http://www.ozlabs.org/~akpm/mmotm/
>
New build failure:
mm/page_alloc.c: In function 'alloc_node_mem_map':
mm/page_alloc.c:4973: error: 'ARCH_PFN_OFFSET' undeclared (first use in this
function)
mm/page_alloc.c:4973: error: (Each undeclared identifier is reported only once
mm/page_alloc.c:4973: error: for each function it appears in.)
make[1]: *** [mm/page_alloc.o] Error 1
Culprit is c2ae2ed329 ("mm/page_alloc.c: don't offset memmap for flatmem").
While the code in question was already there, it is now also built if
CONFIG_FLATMEM is defined. Since the file defining ARCH_PFN_OFFSET
is not directly included, the build now fails for some architectures.
Affected:
avr32:defconfig
avr32:merisc_defconfig
avr32:atngw100mkii_evklcd101_defconfig
m68k:m5272c3_defconfig
m68k:m5307c3_defconfig
m68k:m5249evb_defconfig
m68k:m5407c3_defconfig
mn10300:asb2303_defconfig
mn10300:asb2364_defconfig
Guenter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Intel-gfx] [BUG, bisect] drm/i915: mouse pointer lags and overshoots
all, On Tue, Jan 20, 2015 at 06:48:42AM +0100, Daniel Vetter wrote: > On Mon, Jan 19, 2015 at 08:40:24AM -0800, Matt Roper wrote: > > On Mon, Jan 19, 2015 at 11:04:04AM +, Chris Wilson wrote: > > > On Mon, Jan 19, 2015 at 11:51:43AM +0100, Daniel Vetter wrote: > > > > There's also an issue in (most) X drivers which exaberates this > > > > issues: When changing the cursor buffer the X cursor code does a a) > > > > disable cursor b) update cursor image c) enable cursor cycle. > > > > > > Notably not -intel on which the bug has been observed. And more > > > importantly, the slow downs don't seem to correlate with cursor change, > > > just cursor movement. > > > -Chris > > > > > > -- > > > Chris Wilson, Intel Open Source Technology Centre > > > > It seems that the simple fix for this case (movement only) is to just > > skip the prepare_fb/cleanup_fb calls (and the associated vblank wait) in > > the transitional plane helper when newfb == oldfb. I just posted a > > small patch that makes that change (and solves the cursor lag for me). > > > > This won't solve the case if userspace uses a different framebuffer for > > each update (while trying to update faster than the refresh rate). Is > > there any existing userspace that behaves this way that we can test > > with? > > Hm, I've thought I've merged that patch already: > > commit ab58e3384b9f9863bfd029b458ff337d381bf6d2 > Author: Daniel Vetter > Date: Mon Nov 24 20:42:42 2014 +0100 > > drm/atomic-helper: Skip vblank waits for unchanged fbs > > Or is the problem here that the transitional plane helpers aren't up to > the task? If so please reference that in your patch. > > And we still need a hack for the "changed fb cursor" issue, I'll whip > something up. > -Daniel > -- > Daniel Vetter > Software Engineer, Intel Corporation > +41 (0) 79 365 57 48 - http://blog.ffwll.ch Just checking if anyone has come up with a fix. I am still stuck at next-20150112 because of this bug. -- - Jeremiah Mahler -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [net-next] net: netcp: remove unused kconfig option and code
From: Murali Karicheri Date: Tue, 20 Jan 2015 14:22:36 -0500 > Currently CPTS is built into the netcp driver even though there is no > call out to the CPTS driver. This patch removes the dependency in Kconfig > and remove cpts.o from the Makefile for NetCP. > > Signed-off-by: Murali Karicheri > --- > drivers/net/ethernet/ti/Kconfig |2 +- > drivers/net/ethernet/ti/Makefile |2 +- > 2 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/net/ethernet/ti/Kconfig b/drivers/net/ethernet/ti/Kconfig > index e11bcfa..824e376 100644 > --- a/drivers/net/ethernet/ti/Kconfig > +++ b/drivers/net/ethernet/ti/Kconfig > @@ -73,7 +73,7 @@ config TI_CPSW > config TI_CPTS > boolean "TI Common Platform Time Sync (CPTS) Support" > depends on TI_CPSW > - depends on TI_CPSW || TI_KEYSTONE_NET > + depends on TI_CPSW Just remove the second dependency line, it's redundant because you've made it identical to the line before it. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: mmotm 2015-01-22-15-04: qemu failures due to 'mm: account pmd page tables to the process'
On Fri, Jan 23, 2015 at 01:55:19PM -0800, Andrew Morton wrote:
> On Fri, 23 Jan 2015 07:07:56 -0800 Guenter Roeck wrote:
>
> > >>
> > >> qemu:microblaze generates warnings to the console.
> > >>
> > >> WARNING: CPU: 0 PID: 32 at mm/mmap.c:2858 exit_mmap+0x184/0x1a4()
> > >>
> > >> with various call stacks. See
> > >> http://server.roeck-us.net:8010/builders/qemu-microblaze-mmotm/builds/15/steps/qemubuildcommand/logs/stdio
> > >> for details.
> > >
> > > Could you try patch below? Completely untested.
> > >
> > >>From b584bb8d493794f67484c0b57c161d61c02599bc Mon Sep 17 00:00:00 2001
> > > From: "Kirill A. Shutemov"
> > > Date: Fri, 23 Jan 2015 13:08:26 +0200
> > > Subject: [PATCH] microblaze: define __PAGETABLE_PMD_FOLDED
> > >
> > > Microblaze uses custom implementation of PMD folding, but doesn't define
> > > __PAGETABLE_PMD_FOLDED, which generic code expects to see. Let's fix it.
> > >
> > > Defining __PAGETABLE_PMD_FOLDED will drop out unused __pmd_alloc().
> > > It also fixes problems with recently-introduced pmd accounting.
> > >
> > > Signed-off-by: Kirill A. Shutemov
> > > Reported-by: Guenter Roeck
> >
> > Tested working.
> >
> > Tested-by: Guenter Roeck
> >
> > Any idea how to fix the sh problem ?
>
> Can you tell us more about it? All I'm seeing is "qemu:sh fails to
> shut down", which isn't very clear.
Turns out that the include file defining __PAGETABLE_PMD_FOLDED
was not always included where used, resulting in a messed up mm_struct.
The patch below fixes the problem for the sh architecture.
No idea if the patch is correct/acceptable for other architectures.
Guenter
---
>From 2a11491a5d0642c924db1d78f2b8f21985459062 Mon Sep 17 00:00:00 2001
From: Guenter Roeck
Date: Fri, 23 Jan 2015 21:44:06 -0800
Subject: [PATCH] mm_types: include asm/pgtable.h
Commit 22310c209483 ("mm: account pmd page tables to the process") starts using
__PAGETABLE_PMD_FOLDED in mm_types.h. This define is usually declared in
pgtable.h, so pgtable.h neeeds to be included.
Fixes runtime error with sh targets.
Fixes: 22310c209483 ("mm: account pmd page tables to the process")
Signed-off-by: Guenter Roeck
---
include/linux/mm_types.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
index 79cdf6f..65db573 100644
--- a/include/linux/mm_types.h
+++ b/include/linux/mm_types.h
@@ -13,6 +13,7 @@
#include
#include
#include
+#include
#include
#ifndef AT_VECTOR_SIZE_ARCH
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Staging: dgnc: dgnc_driver.c: fixed twelve coding style warnings
Fixed 80 line warning in the code.
Signed-off-by: Sakshi Bansal
---
drivers/staging/dgnc/dgnc_driver.c | 36
1 file changed, 24 insertions(+), 12 deletions(-)
diff --git a/drivers/staging/dgnc/dgnc_driver.c
b/drivers/staging/dgnc/dgnc_driver.c
index ba98ff3..86028af 100644
--- a/drivers/staging/dgnc/dgnc_driver.c
+++ b/drivers/staging/dgnc/dgnc_driver.c
@@ -60,7 +60,8 @@ static void dgnc_init_globals(void);
static int dgnc_found_board(struct pci_dev *pdev, int id);
static voiddgnc_cleanup_board(struct dgnc_board *brd);
static voiddgnc_poll_handler(ulong dummy);
-static int dgnc_init_one(struct pci_dev *pdev, const struct
pci_device_id *ent);
+static int dgnc_init_one(struct pci_dev *pdev,
+ const struct pci_device_id *ent);
static voiddgnc_do_remap(struct dgnc_board *brd);
/*
@@ -92,16 +93,22 @@ static struct class *dgnc_class;
* Poller stuff
*/
static DEFINE_SPINLOCK(dgnc_poll_lock); /* Poll scheduling lock */
-static ulong dgnc_poll_time; /* Time of next
poll */
-static uintdgnc_poll_stop; /* Used to tell
poller to stop */
+static ulong dgnc_poll_time; /* Time of next
+ poll */
+static uintdgnc_poll_stop; /* Used to tell
+ poller to
stop */
static struct timer_list dgnc_poll_timer;
static struct pci_device_id dgnc_pci_tbl[] = {
- { DIGI_VID, PCI_DEVICE_CLASSIC_4_DID, PCI_ANY_ID, PCI_ANY_ID, 0,
0, 0 },
- { DIGI_VID, PCI_DEVICE_CLASSIC_4_422_DID, PCI_ANY_ID, PCI_ANY_ID,
0, 0, 1 },
- { DIGI_VID, PCI_DEVICE_CLASSIC_8_DID, PCI_ANY_ID, PCI_ANY_ID, 0,
0, 2 },
- { DIGI_VID, PCI_DEVICE_CLASSIC_8_422_DID, PCI_ANY_ID, PCI_ANY_ID,
0, 0, 3 },
+ { DIGI_VID, PCI_DEVICE_CLASSIC_4_DID, PCI_ANY_ID, PCI_ANY_ID, 0,
+ 0, 0 },
+ { DIGI_VID, PCI_DEVICE_CLASSIC_4_422_DID, PCI_ANY_ID, PCI_ANY_ID,
+ 0, 0, 1 },
+ { DIGI_VID, PCI_DEVICE_CLASSIC_8_DID, PCI_ANY_ID, PCI_ANY_ID, 0,
+ 0, 2 },
+ { DIGI_VID, PCI_DEVICE_CLASSIC_8_422_DID, PCI_ANY_ID, PCI_ANY_ID,
+ 0, 0, 3 },
{0,}/* 0 terminated list. */
};
MODULE_DEVICE_TABLE(pci, dgnc_pci_tbl);
@@ -214,7 +221,8 @@ static int __init dgnc_init_module(void)
* If something went wrong in the scan, bail out of driver.
*/
if (rc < 0) {
- /* Only unregister the pci driver if it was actually
registered. */
+ /* Only unregister the pci driver if it was actually registered.
+*/
if (dgnc_NumBoards)
pci_unregister_driver(_driver);
else
@@ -533,7 +541,8 @@ static int dgnc_found_board(struct pci_dev *pdev, int id)
if (brd->re_map_membase) {
- /* After remap is complete, we need to read and store
the dvid */
+ /* After remap is complete, we need to read and store
+* the dvid */
brd->dvid = readb(brd->re_map_membase + 0x8D);
/* Get and store the board VPD, if it exists */
@@ -586,7 +595,8 @@ static int dgnc_found_board(struct pci_dev *pdev, int id)
dgnc_create_ports_sysfiles(brd);
/* init our poll helper tasklet */
- tasklet_init(>helper_tasklet, brd->bd_ops->tasklet, (unsigned
long) brd);
+ tasklet_init(>helper_tasklet, brd->bd_ops->tasklet,
+ (unsigned long) brd);
spin_lock_irqsave(_global_lock, flags);
brd->msgbuf = NULL;
@@ -688,7 +698,8 @@ static void dgnc_poll_handler(ulong dummy)
spin_lock_irqsave(>bd_lock, flags);
- /* If board is in a failed state, don't bother scheduling a
tasklet */
+ /* If board is in a failed state, don't bother scheduling a
+* tasklet */
if (brd->state == BOARD_FAILED) {
spin_unlock_irqrestore(>bd_lock, flags);
continue;
@@ -709,7 +720,8 @@ static void dgnc_poll_handler(ulong dummy)
new_time = dgnc_poll_time - jiffies;
if ((ulong) new_time >= 2 * dgnc_poll_tick)
- dgnc_poll_time = jiffies +
dgnc_jiffies_from_ms(dgnc_poll_tick);
+ dgnc_poll_time = jiffies +
+dgnc_jiffies_from_ms(dgnc_poll_tick);
init_timer(_poll_timer);
dgnc_poll_timer.function = dgnc_poll_handler;
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel"
[PATCH] Staging: dgnc: dgnc_cls.h: fixed four coding style warnings
Fixed 80 line warning in the code comments.
Signed-off-by: Sakshi Bansal
---
drivers/staging/dgnc/dgnc_cls.h | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/dgnc/dgnc_cls.h b/drivers/staging/dgnc/dgnc_cls.h
index 465d79a..7444b00 100644
--- a/drivers/staging/dgnc/dgnc_cls.h
+++ b/drivers/staging/dgnc/dgnc_cls.h
@@ -38,7 +38,8 @@
struct cls_uart_struct {
u8 txrx;/* WR RHR/THR - Holding Reg */
u8 ier; /* WR IER - Interrupt Enable Reg */
- u8 isr_fcr; /* WR ISR/FCR - Interrupt Status Reg/Fifo
Control Reg */
+ u8 isr_fcr; /* WR ISR/FCR - Interrupt Status Reg/Fifo
+ Control Reg */
u8 lcr; /* WR LCR - Line Control Reg */
u8 mcr; /* WR MCR - Modem Control Reg */
u8 lsr; /* WR LSR - Line Status Reg */
@@ -61,7 +62,8 @@ struct cls_uart_struct {
#define UART_16654_FCR_RXTRIGGER_560x80
#define UART_16654_FCR_RXTRIGGER_60 0xC0
-#define UART_IIR_CTSRTS0x20/* Received CTS/RTS
change of state */
+#define UART_IIR_CTSRTS0x20/* Received CTS/RTS
change of
+ state */
#define UART_IIR_RDI_TIMEOUT 0x0C/* Receiver data TIMEOUT */
/*
@@ -74,8 +76,10 @@ struct cls_uart_struct {
#define UART_EXAR654_EFR_RTSDTR 0x40/* Auto RTS/DTR Flow Control Enable
*/
#define UART_EXAR654_EFR_CTSDSR 0x80/* Auto CTS/DSR Flow COntrol Enable
*/
-#define UART_EXAR654_XOFF_DETECT 0x1 /* Indicates whether chip saw an
incoming XOFF char */
-#define UART_EXAR654_XON_DETECT 0x2 /* Indicates whether chip saw an
incoming XON char */
+#define UART_EXAR654_XOFF_DETECT 0x1 /* Indicates whether chip saw an
+incoming XOFF char */
+#define UART_EXAR654_XON_DETECT 0x2 /* Indicates whether chip saw an
+incoming XON char */
#define UART_EXAR654_IER_XOFF 0x20/* Xoff Interrupt Enable */
#define UART_EXAR654_IER_RTSDTR 0x40/* Output Interrupt Enable */
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3] ARM: exynos_defconfig Enable CONFIG_LOCKUP_DETECTOR.
On 01/13/15 17:18, Krzysztof Kozlowski wrote: > On wto, 2015-01-13 at 00:20 +0530, Anand Moon wrote: >> On enabling CONFIG_LOCKUP_DETECTOR the kernel to act as a watchdog >> to detect hard and soft lockups. Enabling CONFIG_LOCKUP_DETECTOR >> don't introduce much overhead on exyons SOC. >> >> CONFIG_LOCKUP_DETECTOR is enabled on multi_v7_defconfig. >> >> Changes since v3: >> * Made commit message more clear >> * Corrected difference between CONFIG_LOCKUP_DETECTOR and CONFIG_LOCKDEP. >> >> Tested on Exynos5422 ODROID XU3 board. >> >> Reviewed-by: Krzysztof Kozlowski >> Signed-off-by: Anand Moon > > Now it looks okay. My reviewed-by may stay on. > Thanks, applied - Kukjin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: exynos_defconfig: Enable PMIC and MUIC drivers for Gears and Trats2
On 01/23/15 23:22, Krzysztof Kozlowski wrote: > Enable drivers for PMICs and MUICs present on Exynos-based devices: > - max14577: charger, extcon, fuel gauge (max17040), regulator, >used on: Gear 1, Gear 2, > - max77693: charger, extcon, fuel gauge (max17042), >used on: Trats2, > > This allows full usage of charging stack on these devices along with > extcon connector. > > Signed-off-by: Krzysztof Kozlowski > --- > arch/arm/configs/exynos_defconfig | 9 + > 1 file changed, 9 insertions(+) > > diff --git a/arch/arm/configs/exynos_defconfig > b/arch/arm/configs/exynos_defconfig > index 3d0c5d65c741..01758378a1b1 100644 > --- a/arch/arm/configs/exynos_defconfig > +++ b/arch/arm/configs/exynos_defconfig > @@ -83,6 +83,10 @@ CONFIG_I2C_S3C2410=y > CONFIG_DEBUG_GPIO=y > CONFIG_POWER_SUPPLY=y > CONFIG_BATTERY_SBS=y > +CONFIG_BATTERY_MAX17040=y > +CONFIG_BATTERY_MAX17042=y > +CONFIG_CHARGER_MAX14577=y > +CONFIG_CHARGER_MAX77693=y > CONFIG_CHARGER_TPS65090=y > CONFIG_HWMON=y > CONFIG_SENSORS_LM90=y > @@ -94,6 +98,7 @@ CONFIG_S3C2410_WATCHDOG=y > CONFIG_MFD_CROS_EC=y > CONFIG_MFD_CROS_EC_I2C=y > CONFIG_MFD_CROS_EC_SPI=y > +CONFIG_MFD_MAX14577=y > CONFIG_MFD_MAX77686=y > CONFIG_MFD_MAX77693=y > CONFIG_MFD_MAX8997=y > @@ -102,6 +107,7 @@ CONFIG_MFD_TPS65090=y > CONFIG_REGULATOR=y > CONFIG_REGULATOR_FIXED_VOLTAGE=y > CONFIG_REGULATOR_GPIO=y > +CONFIG_REGULATOR_MAX14577=y > CONFIG_REGULATOR_MAX8997=y > CONFIG_REGULATOR_MAX77686=y > CONFIG_REGULATOR_MAX77802=y > @@ -168,6 +174,9 @@ CONFIG_COMMON_CLK_MAX77686=y > CONFIG_COMMON_CLK_MAX77802=y > CONFIG_COMMON_CLK_S2MPS11=y > CONFIG_EXYNOS_IOMMU=y > +CONFIG_EXTCON=y > +CONFIG_EXTCON_MAX14577=y > +CONFIG_EXTCON_MAX77693=y > CONFIG_IIO=y > CONFIG_EXYNOS_ADC=y > CONFIG_PWM=y I've applied, thanks. - Kukjin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] regulator: qcom_rpm: Don't update vreg->uV/mV if rpm_reg_write fails
Ensure get_voltage return correct voltage if set_voltage fails. Signed-off-by: Axel Lin --- drivers/regulator/qcom_rpm-regulator.c | 12 1 file changed, 8 insertions(+), 4 deletions(-) diff --git a/drivers/regulator/qcom_rpm-regulator.c b/drivers/regulator/qcom_rpm-regulator.c index edd0a17..f48b3de 100644 --- a/drivers/regulator/qcom_rpm-regulator.c +++ b/drivers/regulator/qcom_rpm-regulator.c @@ -228,9 +228,11 @@ static int rpm_reg_set_mV_sel(struct regulator_dev *rdev, return uV; mutex_lock(>lock); - vreg->uV = uV; if (vreg->is_enabled) - ret = rpm_reg_write(vreg, req, vreg->uV / 1000); + ret = rpm_reg_write(vreg, req, uV / 1000); + + if (!ret) + vreg->uV = uV; mutex_unlock(>lock); return ret; @@ -253,9 +255,11 @@ static int rpm_reg_set_uV_sel(struct regulator_dev *rdev, return uV; mutex_lock(>lock); - vreg->uV = uV; if (vreg->is_enabled) - ret = rpm_reg_write(vreg, req, vreg->uV); + ret = rpm_reg_write(vreg, req, uV); + + if (!ret) + vreg->uV = uV; mutex_unlock(>lock); return ret; -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC][PATCH v2] procfs: Always expose /proc//map_files/ and make it readable
Currently, /proc//map_files/ is restricted to CAP_SYS_ADMIN, and
is only exposed if CONFIG_CHECKPOINT_RESTORE is set. This interface
is very useful for enumerating the files mapped into a process when
the more verbose information in /proc//maps is not needed.
This patch moves the folder out from behind CHECKPOINT_RESTORE, and
removes the CAP_SYS_ADMIN restrictions. Following the links requires
the ability to ptrace the process in question, so this doesn't allow
an attacker to do anything they couldn't already do before.
Signed-off-by: Calvin Owens
---
Changes in v2: Removed the follow_link() stub that returned -EPERM if
the caller didn't have CAP_SYS_ADMIN, since the caller
in my chroot() scenario gets -EACCES anyway.
fs/proc/base.c | 18 --
1 file changed, 18 deletions(-)
diff --git a/fs/proc/base.c b/fs/proc/base.c
index 3f3d7ae..67b15ac 100644
--- a/fs/proc/base.c
+++ b/fs/proc/base.c
@@ -1632,8 +1632,6 @@ end_instantiate:
return dir_emit(ctx, name, len, 1, DT_UNKNOWN);
}
-#ifdef CONFIG_CHECKPOINT_RESTORE
-
/*
* dname_to_vma_addr - maps a dentry name into two unsigned longs
* which represent vma start and end addresses.
@@ -1660,11 +1658,6 @@ static int map_files_d_revalidate(struct dentry *dentry,
unsigned int flags)
if (flags & LOOKUP_RCU)
return -ECHILD;
- if (!capable(CAP_SYS_ADMIN)) {
- status = -EPERM;
- goto out_notask;
- }
-
inode = dentry->d_inode;
task = get_proc_task(inode);
if (!task)
@@ -1792,10 +1785,6 @@ static struct dentry *proc_map_files_lookup(struct inode
*dir,
int result;
struct mm_struct *mm;
- result = -EPERM;
- if (!capable(CAP_SYS_ADMIN))
- goto out;
-
result = -ENOENT;
task = get_proc_task(dir);
if (!task)
@@ -1849,10 +1838,6 @@ proc_map_files_readdir(struct file *file, struct
dir_context *ctx)
struct map_files_info *p;
int ret;
- ret = -EPERM;
- if (!capable(CAP_SYS_ADMIN))
- goto out;
-
ret = -ENOENT;
task = get_proc_task(file_inode(file));
if (!task)
@@ -2040,7 +2025,6 @@ static const struct file_operations
proc_timers_operations = {
.llseek = seq_lseek,
.release= seq_release_private,
};
-#endif /* CONFIG_CHECKPOINT_RESTORE */
static int proc_pident_instantiate(struct inode *dir,
struct dentry *dentry, struct task_struct *task, const void *ptr)
@@ -2537,9 +2521,7 @@ static const struct inode_operations
proc_task_inode_operations;
static const struct pid_entry tgid_base_stuff[] = {
DIR("task", S_IRUGO|S_IXUGO, proc_task_inode_operations,
proc_task_operations),
DIR("fd", S_IRUSR|S_IXUSR, proc_fd_inode_operations,
proc_fd_operations),
-#ifdef CONFIG_CHECKPOINT_RESTORE
DIR("map_files", S_IRUSR|S_IXUSR, proc_map_files_inode_operations,
proc_map_files_operations),
-#endif
DIR("fdinfo", S_IRUSR|S_IXUSR, proc_fdinfo_inode_operations,
proc_fdinfo_operations),
DIR("ns", S_IRUSR|S_IXUGO, proc_ns_dir_inode_operations,
proc_ns_dir_operations),
#ifdef CONFIG_NET
--
1.8.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/
Darlehen Angebot
Guten Morgen Sind Sie in Darlehen interessiert? Der Preis ist niedrig Für weitere Informationen und Erklärungen Meine E-Mail: info.krause.a...@gmail.com Danke -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: mmotm 2015-01-22-15-04: qemu failures due to 'mm: account pmd page tables to the process'
On 01/23/2015 06:44 PM, Guenter Roeck wrote: On 01/23/2015 01:55 PM, Andrew Morton wrote: On Fri, 23 Jan 2015 07:07:56 -0800 Guenter Roeck wrote: qemu:microblaze generates warnings to the console. WARNING: CPU: 0 PID: 32 at mm/mmap.c:2858 exit_mmap+0x184/0x1a4() with various call stacks. See http://server.roeck-us.net:8010/builders/qemu-microblaze-mmotm/builds/15/steps/qemubuildcommand/logs/stdio for details. Could you try patch below? Completely untested. >From b584bb8d493794f67484c0b57c161d61c02599bc Mon Sep 17 00:00:00 2001 From: "Kirill A. Shutemov" Date: Fri, 23 Jan 2015 13:08:26 +0200 Subject: [PATCH] microblaze: define __PAGETABLE_PMD_FOLDED Microblaze uses custom implementation of PMD folding, but doesn't define __PAGETABLE_PMD_FOLDED, which generic code expects to see. Let's fix it. Defining __PAGETABLE_PMD_FOLDED will drop out unused __pmd_alloc(). It also fixes problems with recently-introduced pmd accounting. Signed-off-by: Kirill A. Shutemov Reported-by: Guenter Roeck Tested working. Tested-by: Guenter Roeck Any idea how to fix the sh problem ? Can you tell us more about it? All I'm seeing is "qemu:sh fails to shut down", which isn't very clear. qemu command line: /opt/buildbot/bin/qemu-system-sh4 -M r2d -kernel ./arch/sh/boot/zImage \ -drive file=rootfs.ext2,if=ide \ -append "root=/dev/sda console=ttySC1,115200 noiotrap" -serial null -serial stdio -net nic,model=rtl8139 -net user -nographic -monitor null -- Poweroff log in mainline (v3.19-rc5-119-gb942c65): / # poweroff The system is going down NOW! Sent SIGTERM to all processes Sent SIGKILL to all processes Requesting system poweroff sd 0:0:0:0: [sda] Synchronizing SCSI cache sd 0:0:0:0: [sda] Stopping disk reboot: Power down -- Poweroff log in mmotm (v3.19-rc5-417-gc64429b): / # poweroff [ nothing else happens until I kill the qemu session ] The "halt" command does not work either. -- The message "The system is going down NOW" is from the init process. If I use "kill -12 1" instead of "halt" or "poweroff", the system does shut down as expected. "poweroff -f" also works. Trying to debug this further, I noticed that the "ps" command hangs as well, so the problem is not limited to poweroff or halt. I'll be happy to debug this further, I just have no idea where to start. Another data point: Reverting commit 22310c209483 does fix the problem. Guenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/5 v2] tracing: Automatically mount tracefs on debugfs/tracing
On Fri, Jan 23, 2015 at 10:55:28AM -0500, Steven Rostedt wrote:
> From: "Steven Rostedt (Red Hat)"
>
> As tools currently rely on the tracing directory in debugfs, we can not
> just created a tracefs infrastructure and expect sysadmins to mount
> the new tracefs to have their old tools work.
>
> Instead, the debugfs tracing directory is still created and the tracefs
> file system is mounted there when the debugfs filesystem is mounted.
>
> No longer does the tracing infrastructure update the debugfs file system,
> but instead interacts with the tracefs file system. But now, it still
> appears to the user like nothing changed, except you also have the feature
> of mounting just the tracing system without needing all of debugfs!
>
> Note, because debugfs_create_dir() happens to end up setting the
> dentry->d_op, we can not use d_set_d_op() but must manually assign the
> new op, that has automount set, to the dentry returned. This can be
> racy, but since this happens during the initcall sequence on boot up,
> there should be nothing that races with it.
>
> Cc: Al Viro
> Signed-off-by: Steven Rostedt
> ---
> kernel/trace/trace.c | 51 ++-
> 1 file changed, 50 insertions(+), 1 deletion(-)
>
> diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
> index fb577a2a60ea..4fb557917d39 100644
> --- a/kernel/trace/trace.c
> +++ b/kernel/trace/trace.c
> @@ -32,6 +32,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -5815,10 +5816,35 @@ static __init int register_snapshot_cmd(void)
> static inline __init int register_snapshot_cmd(void) { return 0; }
> #endif /* defined(CONFIG_TRACER_SNAPSHOT) && defined(CONFIG_DYNAMIC_FTRACE)
> */
>
> +static struct vfsmount *trace_automount(struct path *path)
> +{
> + struct vfsmount *mnt;
> + struct file_system_type *type;
> +
> + /*
> + * To maintain backward compatibility for tools that mount
> + * debugfs to get to the tracing facility, tracefs is automatically
> + * mounted to the debugfs/tracing directory.
> + */
> + type = get_fs_type("tracefs");
> + if (!type)
> + return NULL;
> + mnt = vfs_kern_mount(type, 0, "tracefs", NULL);
> + put_filesystem(type);
> + if (IS_ERR(mnt))
> + return NULL;
> + mntget(mnt);
> +
> + return mnt;
> +}
> +
> #define TRACE_TOP_DIR_ENTRY ((struct dentry *)1)
>
> struct dentry *tracing_init_dentry_tr(struct trace_array *tr)
> {
> + static struct dentry_operations trace_ops;
> + struct dentry *traced;
> +
> /* Top entry does not have a descriptor */
> if (tr->dir == TRACE_TOP_DIR_ENTRY)
> return NULL;
> @@ -5831,7 +5857,30 @@ struct dentry *tracing_init_dentry_tr(struct
> trace_array *tr)
> return ERR_PTR(-ENODEV);
>
> if (tr->flags & TRACE_ARRAY_FL_GLOBAL) {
> - tr->dir = debugfs_create_dir("tracing", NULL);
> + traced = debugfs_create_dir("tracing", NULL);
> + if (!traced)
> + return ERR_PTR(-ENOMEM);
> + /* copy the dentry ops and add an automount to it */
> + if (traced->d_op) {
> + /*
> + * FIXME:
> + * Currently debugfs sets the d_op by a side-effect
> + * of calling simple_lookup(). Normally, we should
> + * never change d_op of a dentry, but as this is
> + * happening at boot up and shouldn't be racing with
> + * any other users, this should be OK. But it is still
> + * a hack, and needs to be properly done.
> + */
> + trace_ops = *traced->d_op;
> + trace_ops.d_automount = trace_automount;
> + traced->d_flags |= DCACHE_NEED_AUTOMOUNT;
> + traced->d_op = _ops;
> + } else {
> + /* Ideally, this is what should happen */
> + trace_ops = simple_dentry_operations;
> + trace_ops.d_automount = trace_automount;
> + d_set_d_op(traced, _ops);
How will this else block run if debugfs is setting d_op in the
debugfs_create_dir() call?
What really do you want to do here, just automount a filesystem on
debugfs? If so, can't we just add a new debugfs call to do that?
thanks,
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/5 v2] tracefs: Add directory /sys/kernel/tracing
On Fri, Jan 23, 2015 at 10:55:29AM -0500, Steven Rostedt wrote:
> From: "Steven Rostedt (Red Hat)"
>
> When tracefs is configured, have the directory /sys/kernel/tracing appear
> just like /sys/kernel/debug appears when debugfs is configured.
>
> This will give a consistent place for system admins to mount tracefs.
>
> Signed-off-by: Steven Rostedt
> ---
> fs/tracefs/inode.c | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/fs/tracefs/inode.c b/fs/tracefs/inode.c
> index c31997a303c7..cdbaa42b44a1 100644
> --- a/fs/tracefs/inode.c
> +++ b/fs/tracefs/inode.c
> @@ -16,6 +16,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -547,10 +548,16 @@ bool tracefs_initialized(void)
> return tracefs_registered;
> }
>
> +static struct kobject *trace_kobj;
> +
> static int __init tracefs_init(void)
> {
> int retval;
>
> + trace_kobj = kobject_create_and_add("tracing", kernel_kobj);
> + if (!trace_kobj)
> + return -EINVAL;
> +
> retval = register_filesystem(_fs_type);
> if (!retval)
> tracefs_registered = true;
> --
> 2.1.4
>
Acked-by: Greg Kroah-Hartman
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[clk:test-sched-packing-tasks-freq 10820/10847] kernel/sched/fair.c:199:1: sparse: symbol '__pcpu_scope_sd_pack_buddy' was not declared. Should it be static?
tree: https://git.linaro.org/people/mturquette/linux.git test-sched-packing-tasks-freq head: 3add111981928a9ce810cd1b1956dc39e6c2445f commit: 9cb183281a03911e724a648832d9f096c09197fe [10820/10847] sched: packing tasks reproduce: # apt-get install sparse git checkout 9cb183281a03911e724a648832d9f096c09197fe make ARCH=x86_64 allmodconfig make C=1 CF=-D__CHECK_ENDIAN__ sparse warnings: (new ones prefixed by >>) kernel/sched/fair.c:51:14: sparse: symbol 'normalized_sysctl_sched_latency' was not declared. Should it be static? kernel/sched/fair.c:70:14: sparse: symbol 'normalized_sysctl_sched_min_granularity' was not declared. Should it be static? kernel/sched/fair.c:92:14: sparse: symbol 'normalized_sysctl_sched_wakeup_granularity' was not declared. Should it be static? >> kernel/sched/fair.c:199:1: sparse: symbol '__pcpu_scope_sd_pack_buddy' was >> not declared. Should it be static? kernel/sched/sched.h:765:9: sparse: incompatible types in comparison expression (different address spaces) kernel/sched/fair.c:249:22: sparse: incompatible types in comparison expression (different address spaces) kernel/sched/fair.c:4993:14: sparse: incompatible types in comparison expression (different address spaces) kernel/sched/fair.c:1666:14: sparse: incompatible types in comparison expression (different address spaces) kernel/sched/fair.c:2168:15: sparse: incompatible types in comparison expression (different address spaces) kernel/sched/fair.c:7571:22: sparse: incompatible types in comparison expression (different address spaces) kernel/sched/fair.c:7586:9: sparse: incompatible types in comparison expression (different address spaces) kernel/sched/fair.c:5070:9: sparse: incompatible types in comparison expression (different address spaces) kernel/sched/fair.c:5126:17: sparse: incompatible types in comparison expression (different address spaces) kernel/sched/fair.c:5706:41: sparse: incompatible types in comparison expression (different address spaces) kernel/sched/fair.c:5742:41: sparse: incompatible types in comparison expression (different address spaces) kernel/sched/fair.c:7688:9: sparse: incompatible types in comparison expression (different address spaces) kernel/sched/fair.c:7755:17: sparse: incompatible types in comparison expression (different address spaces) kernel/sched/fair.c:7839:14: sparse: incompatible types in comparison expression (different address spaces) kernel/sched/fair.c:7727:16: sparse: incompatible types in comparison expression (different address spaces) kernel/sched/fair.c:7921:9: sparse: incompatible types in comparison expression (different address spaces) kernel/sched/fair.c:7727:16: sparse: incompatible types in comparison expression (different address spaces) kernel/sched/fair.c:7822:14: sparse: incompatible types in comparison expression (different address spaces) kernel/sched/fair.c:8091:14: sparse: incompatible types in comparison expression (different address spaces) kernel/sched/fair.c:8103:14: sparse: incompatible types in comparison expression (different address spaces) kernel/sched/fair.c:8112:14: sparse: incompatible types in comparison expression (different address spaces) Please review and possibly fold the followup patch. --- 0-DAY kernel test infrastructureOpen Source Technology Center http://lists.01.org/mailman/listinfo/kbuild Intel Corporation -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 clk] sched: __pcpu_scope_sd_pack_buddy can be static
kernel/sched/fair.c:199:1: sparse: symbol '__pcpu_scope_sd_pack_buddy' was not
declared. Should it be static?
Signed-off-by: Fengguang Wu
---
fair.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index d48d07c..7d8d5c4 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -196,7 +196,7 @@ struct sd_pack {
* Save per_cpu information about the optimal CPUs that should be used to pack
* tasks.
*/
-DEFINE_PER_CPU(struct sd_pack, sd_pack_buddy) = {
+static DEFINE_PER_CPU(struct sd_pack, sd_pack_buddy) = {
.packing = true,
};
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: mmotm 2015-01-22-15-04: qemu failures due to 'mm: account pmd page tables to the process'
On 01/23/2015 01:55 PM, Andrew Morton wrote: On Fri, 23 Jan 2015 07:07:56 -0800 Guenter Roeck wrote: qemu:microblaze generates warnings to the console. WARNING: CPU: 0 PID: 32 at mm/mmap.c:2858 exit_mmap+0x184/0x1a4() with various call stacks. See http://server.roeck-us.net:8010/builders/qemu-microblaze-mmotm/builds/15/steps/qemubuildcommand/logs/stdio for details. Could you try patch below? Completely untested. >From b584bb8d493794f67484c0b57c161d61c02599bc Mon Sep 17 00:00:00 2001 From: "Kirill A. Shutemov" Date: Fri, 23 Jan 2015 13:08:26 +0200 Subject: [PATCH] microblaze: define __PAGETABLE_PMD_FOLDED Microblaze uses custom implementation of PMD folding, but doesn't define __PAGETABLE_PMD_FOLDED, which generic code expects to see. Let's fix it. Defining __PAGETABLE_PMD_FOLDED will drop out unused __pmd_alloc(). It also fixes problems with recently-introduced pmd accounting. Signed-off-by: Kirill A. Shutemov Reported-by: Guenter Roeck Tested working. Tested-by: Guenter Roeck Any idea how to fix the sh problem ? Can you tell us more about it? All I'm seeing is "qemu:sh fails to shut down", which isn't very clear. qemu command line: /opt/buildbot/bin/qemu-system-sh4 -M r2d -kernel ./arch/sh/boot/zImage \ -drive file=rootfs.ext2,if=ide \ -append "root=/dev/sda console=ttySC1,115200 noiotrap" -serial null -serial stdio -net nic,model=rtl8139 -net user -nographic -monitor null -- Poweroff log in mainline (v3.19-rc5-119-gb942c65): / # poweroff The system is going down NOW! Sent SIGTERM to all processes Sent SIGKILL to all processes Requesting system poweroff sd 0:0:0:0: [sda] Synchronizing SCSI cache sd 0:0:0:0: [sda] Stopping disk reboot: Power down -- Poweroff log in mmotm (v3.19-rc5-417-gc64429b): / # poweroff [ nothing else happens until I kill the qemu session ] The "halt" command does not work either. -- The message "The system is going down NOW" is from the init process. If I use "kill -12 1" instead of "halt" or "poweroff", the system does shut down as expected. "poweroff -f" also works. Trying to debug this further, I noticed that the "ps" command hangs as well, so the problem is not limited to poweroff or halt. I'll be happy to debug this further, I just have no idea where to start. Thanks, Guenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] sched, x86: Prevent resched interrupts if task in kernel mode and !CONFIG_PREEMPT
On Fri, Jan 23, 2015 at 9:09 AM, Kirill Tkhai wrote: > В Пт, 23/01/2015 в 08:24 -0800, Andy Lutomirski пишет: >> On Fri, Jan 23, 2015 at 8:07 AM, Peter Zijlstra wrote: >> > On Fri, Jan 23, 2015 at 06:53:32PM +0300, Kirill Tkhai wrote: >> >> --- >> >> arch/x86/kernel/entry_64.S | 10 ++ >> >> 1 file changed, 10 insertions(+) >> >> >> >> diff --git a/arch/x86/kernel/entry_64.S b/arch/x86/kernel/entry_64.S >> >> index c653dc4..a046ba8 100644 >> >> --- a/arch/x86/kernel/entry_64.S >> >> +++ b/arch/x86/kernel/entry_64.S >> >> @@ -409,6 +409,13 @@ GLOBAL(system_call_after_swapgs) >> >> movq_cfi rax,(ORIG_RAX-ARGOFFSET) >> >> movq %rcx,RIP-ARGOFFSET(%rsp) >> >> CFI_REL_OFFSET rip,RIP-ARGOFFSET >> >> +#if !defined(CONFIG_PREEMPT) || !defined(SMP) >> >> + /* >> >> + * Tell resched_curr() do not send useless interrupts to us. >> >> + * Kernel isn't preemptible till sysret_careful() anyway. >> >> + */ >> >> + LOCK ; bts >> >> $TIF_POLLING_NRFLAG,TI_flags+THREAD_INFO(%rsp,RIP-ARGOFFSET) >> >> +#endif >> >> That's kind of expensive. What's the !SMP part for? > > smp_send_reschedule() is NOP on UP. There is no problem. Shouldn't it be #if !defined(CONFIG_PREEMPT) && defined(CONFIG_SMP) then? > >> >> >> testl >> >> $_TIF_WORK_SYSCALL_ENTRY,TI_flags+THREAD_INFO(%rsp,RIP-ARGOFFSET) >> >> jnz tracesys >> >> system_call_fastpath: >> >> @@ -427,6 +434,9 @@ GLOBAL(system_call_after_swapgs) >> >> * Has incomplete stack frame and undefined top of stack. >> >> */ >> >> ret_from_sys_call: >> >> +#if !defined(CONFIG_PREEMPT) || !defined(SMP) >> >> + LOCK ; btr >> >> $TIF_POLLING_NRFLAG,TI_flags+THREAD_INFO(%rsp,RIP-ARGOFFSET) >> >> +#endif >> >> If only it were this simple. There are lots of ways out of syscalls, >> and this is only one of them :( If we did this, I'd rather do it >> through the do_notify_resume mechanism or something. > > Yes, syscall is the only thing I did as an example. > >> I don't see any way to do this without at least one atomic op or >> smp_mb per syscall, and that's kind of expensive. > > JFI, doesn't x86 set_bit() lock a small area of memory? I thought > it's not very expensive on this arch (some bus optimizations or > something like this). An entire syscall on x86 is well under 200 cycles. lock addl is >20 cycles for me, and I don't see why the atomic bitops would be faster. (Oddly, mfence is slower than lock addl, which is really odd, since lock addl implies mfence.) So this overhead may actually matter. > >> Would it make sense to try to use context tracking instead? On >> systems that use context tracking, syscalls are already expensive, and >> we're already keeping track of which CPUs are in user mode. > > I'll look at context_tracking, but I'm not sure some smp synchronization > there. It could be combinable with existing synchronization there. --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 v1 2/2] Staging: comedi: fix line over 80 characters warning
On Sat, Jan 24, 2015 at 12:41:20AM +0530, jitendra kumar khasdev wrote: > This is patch to file jr3_pci.c that fix up warning line > over 80 character which is found by checkpatch tool. Made change into > signature > of struct jr3_pci_poll_delay jr3_pci_poll_subdevice function by giving a > newline > so that 80 character line over warning to be reduced. The irony of not properly line-wrapping your changelog comment for a patch that you are fixing up proper line size is huge :) > > Signed-off-by: Jitendra Kumar Khasdev > --- > drivers/staging/comedi/drivers/jr3_pci.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/drivers/staging/comedi/drivers/jr3_pci.c > b/drivers/staging/comedi/drivers/jr3_pci.c > index 81fab2d..1de843d 100644 > --- a/drivers/staging/comedi/drivers/jr3_pci.c > +++ b/drivers/staging/comedi/drivers/jr3_pci.c > @@ -449,7 +449,8 @@ static int jr3_download_firmware(struct comedi_device > *dev, > return 0; > } > > -static struct jr3_pci_poll_delay jr3_pci_poll_subdevice(struct > comedi_subdevice *s) > +static struct jr3_pci_poll_delay jr3_pci_poll_subdevice(struct > comedi_subdevice > + *s) Be reasonable, this is now looks worse than the code did before, just leave this as-is, coding style is a guideline, not hard rules. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: module: fix module_refcount() return when running in a module exit routine
James Bottomley writes:
> On Fri, 2015-01-23 at 05:17 -0800, Christoph Hellwig wrote:
>> On Fri, Jan 23, 2015 at 01:24:15PM +1030, Rusty Russell wrote:
>> > The correct fix is to turn try_module_get() into __module_get(), and
>> > always do the module_put().
>>
>> Is this really safe? __module_get sais it needs a non-zero refcount
>> to start with, but scsi_device_get is the only thing every incrementing
>> the refcount on the module pointer in the scsi host template, so
>> exactly that case can happen easily. There's not assert actually
>> hardcoding the assumption, so I'm not sure if requirement the comment
>> really just is nice to have or a strong requirement.
Yes, as James says, my patch makes it no worse.
The "someone else grabs a reference" can be fixed in two ways. James'
alternate path as per below, or by waiting in the exit function. The
latter is kind of annoying, which is why we do the whole atomic
deregistration for modules...
Cheers,
Rusty.
> The comment was just documenting the old status quo: the
> try_module_get() was expected to fail if called within the host module
> remove path. If you look at the flow, we use the refcounts on the
> actual scsi device to measure. If they fail we know we have a problem.
> The module stuff is really only slaved to our master refcount on the
> device. It's purpose is to prevent an inopportune rmmod. Our default
> operating state is zero references on everything, so the user can just
> do rmmod ... obviously if the device is open or mounted then we hold
> both the device and the module.
>
> To that point, Rusty's patch just keeps the status quo in the new
> module_refcount() environment, so it's the quick bandaid.
>
> I think the use case you're worrying about is what happens if someone
> tries to use a device after module removal begins executing but before
> the device has been deleted (say by opening it)? We'll exit the device
> removal routines and then kill the module, because after the module code
> gets to ->exit(), nothing re-checks the module refcount, so the host
> module will get free'd while we're still using the device.
>
> The fix for this seems to be to differentiate between special uses of
> scsi_get_device, which are allowed to get the device in the module exit
> routines and ordinary uses which aren't. Something like this? (the
> patch isn't complete, but you get the idea).
>
> James
>
> ---
>
> diff --git a/drivers/scsi/scsi.c b/drivers/scsi/scsi.c
> index 08c90a7..31ba254 100644
> --- a/drivers/scsi/scsi.c
> +++ b/drivers/scsi/scsi.c
> @@ -965,6 +965,15 @@ int scsi_report_opcode(struct scsi_device *sdev,
> unsigned char *buffer,
> }
> EXPORT_SYMBOL(scsi_report_opcode);
>
> +static int __scsi_device_get_common(struct scsi_device *sdev)
> +{
> + if (sdev->sdev_state == SDEV_DEL)
> + return -ENXIO;
> + if (!get_device(>sdev_gendev))
> + return -ENXIO;
> + return 0;
> +}
> +
> /**
> * scsi_device_get - get an additional reference to a scsi_device
> * @sdev:device to get a reference to
> @@ -975,19 +984,45 @@ EXPORT_SYMBOL(scsi_report_opcode);
> */
> int scsi_device_get(struct scsi_device *sdev)
> {
> - if (sdev->sdev_state == SDEV_DEL)
> - return -ENXIO;
> - if (!get_device(>sdev_gendev))
> - return -ENXIO;
> - /* We can fail this if we're doing SCSI operations
> - * from module exit (like cache flush) */
> - try_module_get(sdev->host->hostt->module);
> + int ret;
>
> - return 0;
> + ret = __scsi_device_get_common(sdev);
> + if (ret)
> + return ret;
> +
> + ret = try_module_get(sdev->host->hostt->module);
> +
> + if (ret)
> + put_device(>sdev_gendev);
> +
> + return ret;
> }
> EXPORT_SYMBOL(scsi_device_get);
>
> /**
> + * scsi_device_get_in_module_exit() - get an additional reference to a
> scsi_device
> + * @sdev:device to get a reference to
> + *
> + * Functions identically to scsi_device_get() except that it unconditionally
> + * gets the module reference. This allows it to be called from module exit
> + * routines where scsi_device_get() will fail. This routine is still paired
> + * with scsi_device_put().
> + */
> +int scsi_device_get_in_module_exit(struct scsi_device *sdev)
> +{
> + int ret;
> +
> + ret = __scsi_device_get_common(sdev);
> + if (ret)
> + return ret;
> +
> + __module_get(sdev->host->hostt->module);
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(scsi_device_get_in_module_exit);
> +
> +/**
> * scsi_device_put - release a reference to a scsi_device
> * @sdev:device to release a reference on.
> *
> diff --git a/drivers/scsi/sd.c b/drivers/scsi/sd.c
> index ebf35cb6..057604e 100644
> --- a/drivers/scsi/sd.c
> +++ b/drivers/scsi/sd.c
> @@ -564,16 +564,22 @@ static int sd_major(int major_idx)
> }
> }
>
> -static struct scsi_disk *__scsi_disk_get(struct gendisk *disk)
> +static struct scsi_disk
Re: rcu, sched: WARNING: CPU: 30 PID: 23771 at kernel/rcu/tree_plugin.h:337 rcu_read_unlock_special+0x369/0x550()
On 01/23/2015 05:36 PM, Paul E. McKenney wrote:
> On Thu, Jan 22, 2015 at 10:55:42PM -0800, Paul E. McKenney wrote:
>> On Thu, Jan 22, 2015 at 11:05:45PM -0500, Sasha Levin wrote:
>>> On 01/22/2015 11:02 PM, Sasha Levin wrote:
On 01/22/2015 10:51 PM, Paul E. McKenney wrote:
> On Thu, Jan 22, 2015 at 10:29:01PM -0500, Sasha Levin wrote:
>>> On 01/21/2015 07:43 PM, Paul E. McKenney wrote:
> On Wed, Jan 21, 2015 at 10:44:57AM -0500, Sasha Levin wrote:
>>> On 01/20/2015 09:57 PM, Paul E. McKenney wrote:
> So RCU believes that an RCU read-side critical section that
> ended within
> an interrupt handler (in this case, an hrtimer) somehow
> got preempted.
> Which is not supposed to happen.
>
> Do you have CONFIG_PROVE_RCU enabled? If not, could you
> please enable it
> and retry?
>
> I did have CONFIG_PROVE_RCU, and didn't see anything else
> besides what I pasted here.
> OK, fair enough. I do have a stack of RCU CPU stall-warning
> changes on
> their way in, please see v3.19-rc1..630181c4a915 in -rcu, which
> is at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git
>
> These handle the problems that Dave Jones, yourself, and a few
> others
> located this past December. Could you please give them a spin?
>>>
>>> They seem to be a part of -next already, so this testing already
>>> includes them.
>>>
>>> I seem to be getting them about once a day, anything I can add to
>>> debug it?
>
> Could you please try reproducing with the following patch?
>>>
>>> Yes, and I've got mixed results. It reproduced, and all I got was:
>>>
>>> [ 717.645572] ===
>>> [ 717.645572] [ INFO: suspicious RCU usage. ]
>>> [ 717.645572] 3.19.0-rc5-next-20150121-sasha-00064-g3c37e35-dirty
>>> #1809 Tainted: GW
>>> [ 717.645572] ---
>>> [ 717.645572] kernel/rcu/tree_plugin.h:337 rcu_read_unlock() from irq
>>> or softirq with blocking in critical section!!!
>>> [ 717.645572] !
>>> [ 717.645572]
>>> [ 717.645572] other info that might help us debug this:
>>> [ 717.645572]
>>> [ 717.645572]
>>> [ 717.645572] rcu_scheduler_active = 1, debug_locks = 1
>>> [ 717.645572] 3 locks held by trinity-c29/16497:
>>> [ 717.645572] #0: (>s_type->i_mutex_key){+.+.+.}, at:
>>> [] lookup_slow+0xd3/0x420
>>> [ 717.645572] #1:
>>> [hang]
>>>
>>> So the rest of the locks/stack trace didn't get printed, nor the
>>> pr_alert() which
>>> should follow that.
>>>
>>> I've removed the lockdep call and will re-run it.
> Thank you! You are keeping the pr_alert(), correct?
Yup, just the lockdep call goes away.
>>>
>>> Okay, this reproduced faster than I anticipated:
>>>
>>> [ 786.160131] ->rcu_read_unlock_special: 0x100 (b: 0, nq: 1)
>>> [ 786.239513] ->rcu_read_unlock_special: 0x100 (b: 0, nq: 1)
>>> [ 786.240503] ->rcu_read_unlock_special: 0x100 (b: 0, nq: 1)
>>> [ 786.242575] ->rcu_read_unlock_special: 0x100 (b: 0, nq: 1)
>>> [ 786.243565] ->rcu_read_unlock_special: 0x100 (b: 0, nq: 1)
>>> [ 786.243565] ->rcu_read_unlock_special: 0x100 (b: 0, nq: 1)
>>> [ 786.243565] ->rcu_read_unlock_special: 0x100 (b: 0, nq: 1)
>>> [ 786.243565] ->rcu_read_unlock_special: 0x100 (b: 0, nq: 1)
>>> [ 786.243565] ->rcu_read_unlock_special: 0x100 (b: 0, nq: 1)
>>>
>>> It seems like the WARN_ON_ONCE was hiding the fact it actually got hit
>>> couple
>>> of times in a very short interval. Maybe that would also explain lockdep
>>> crapping
>>> itself.
>>
>> OK, that was what I thought was the situation. I have not yet fully
>> worked out how RCU gets into that state, but in the meantime, here
>> is a patch that should prevent the splats. (It requires a subtle
>> interaction of quiescent-state detection and the scheduling-clock
>> interrupt.)
>
> And I did finally figure out how this can happen. Please see below
> for an updated patch with this information recorded in the commit log.
> Sasha, I am impressed -- your testing not only located a true RCU bug,
> but an RCU bug that can happen on a uniprocessor! ;-)
>
> As far as I know, the bug is harmless apart from the splat, but still...
>
> Thanx, Paul
>
>
>
> rcu: Clear need_qs flag to prevent splat
>
> If the scheduling-clock interrupt sets the current tasks need_qs flag,
> but if the current CPU passes through a quiescent state in the
Re: [PATCH] vt: provide notifications on selection changes
On Fri, Jan 23, 2015 at 05:07:21PM -0500, Nicolas Pitre wrote: > The vcs device's poll/fasync support relies on the vt notifier to signal > changes to the screen content. Notifier invocations were missing for > changes that comes through the selection interface though. Fix that. > > Tested with BRLTTY 5.2. > > Signed-off-by: Nicolas Pitre > Cc: Dave Mielke > > --- > > Greg: Would be highly convenient to have this patch applied to the > stable tree as well to help affected blind Linux users via distro > updates. Yet it took a while before this issue was discovered. Your > call. Ok, that sounds good, I'll queue this up for 3.20-rc1 and mark it for stable so it will get backported. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: mmotm 2015-01-22-15-04: qemu failure due to 'mm: memcontrol: remove unnecessary soft limit tree node test'
On 01/23/2015 09:36 AM, Johannes Weiner wrote:
On Fri, Jan 23, 2015 at 08:59:51AM -0800, Guenter Roeck wrote:
On 01/23/2015 08:02 AM, Johannes Weiner wrote:
On Fri, Jan 23, 2015 at 09:17:44AM -0600, Christoph Lameter wrote:
On Fri, 23 Jan 2015, Johannes Weiner wrote:
Is the assumption of this patch wrong? Does the specified node have
to be online for the fallback to work?
Nodes that are offline have no control structures allocated and thus
allocations will likely segfault when the address of the controls
structure for the node is accessed.
If we wanted to prevent that then every allocation would have to add a
check to see if the nodes are online which would impact performance.
Okay, that makes sense, thank you.
Andrew, can you please drop this patch?
Problem is that there are three patches.
2537ffb mm: memcontrol: consolidate swap controller code
2f9b346 mm: memcontrol: consolidate memory controller initialization
a40d0d2 mm: memcontrol: remove unnecessary soft limit tree node test
Reverting (or dropping) a40d0d2 alone is not possible since it modifies
mem_cgroup_soft_limit_tree_init which is removed by 2f9b346.
("mm: memcontrol: consolidate swap controller code") gave me no issues
when rebasing, but ("mm: memcontrol: consolidate memory controller
initialization") needs updating.
So how about this one to replace ("mm: memcontrol: remove unnecessary
soft limit tree node test"):
---
From: Johannes Weiner
Subject: [patch] mm: memcontrol: simplify soft limit tree init code
- No need to test the node for N_MEMORY. node_online() is enough for
node fallback to work in slab, use NUMA_NO_NODE for everything else.
- Remove the BUG_ON() for allocation failure. A NULL pointer crash is
just as descriptive, and the absent return value check is obvious.
- Move local variables to the inner-most blocks.
- Point to the tree structure after its initialized, not before, it's
just more logical that way.
Signed-off-by: Johannes Weiner
The latest version in mmotm passes my ppc64 qemu test, so it works
at least in this context.
Tested-by: Guenter Roeck
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 1/1] x86: Add Isolated Memory Regions for Quark X1000
Hi Bryan, there are 1 serious bug & couple of minor bugs that I caught...
please fix
>-Original Message-
>From: Bryan O'Donoghue [mailto:pure.lo...@nexus-software.ie]
>Sent: Wednesday, January 21, 2015 10:46 AM
>To: t...@linutronix.de; mi...@redhat.com; h...@zytor.com; x...@kernel.org;
>dvh...@infradead.org; andy.shevche...@gmail.com; Ong, Boon Leong; linux-
>ker...@vger.kernel.org
>Cc: Bryan O'Donoghue
>Subject: [PATCH v2 1/1] x86: Add Isolated Memory Regions for Quark X1000
>
>From V1 comment:
Suggest to add a statement on 3 different types of IMR: General IMR, Host Memory
I/O Boundary IMR & System Management Mode IMR. Then, call out that this patch
is meant to support general IMR type only.
>Intel's Quark X1000 SoC contains a set of registers called Isolated Memory
>Regions. IMRs are accessed over the IOSF mailbox interface. IMRs are areas
>carved out of memory that define read/write access rights to the various
>system agents within the Quark system. For a given agent in the system it is
>possible to specify if that agent may read or write an area of memory
>defined by an IMR with a granularity of 1 KiB.
>
>Quark_SecureBootPRM_330234_001.pdf section 4.5 details the concept of IMRs
>quark-x1000-datasheet.pdf section 12.7.4 details the implementation of IMRs
>in silicon.
>
>eSRAM flush, CPU Snoop, CPU SMM Mode, CPU non-SMM mode, RMU and PCIe
>Virtual
>Channels (VC0 and VC1) can have individual read/write access masks applied
>to them for a given memory region in Quark X1000. This enables IMRs to treat
>each memory transaction type listed above on an individual basis and to
>filter appropriately based on the IMR access mask for the memory region.
>Quark supports eight IMRs.
For CPU Snoop, to add (write-only)
>+
>+/**
>+ * imr_enabled - true if an IMR is enabled false otherwise
>+ *
>+ * Determines if an IMR is enabled based on address range and read/write
>+ * mask. An IMR set with an address range set to zero and a read/write
>+ * access mask set to all is considered to be disabled. An IMR in any
>+ * other state - for example set to zero but without read/write access
>+ * all is considered to be enabled. This definition of disabled is how
>+ * firmware switches off an IMR and is maintained in kernel for
>+ * consistency.
>+ *
>+ * @imr: pointer to IMR descriptor
>+ * @return: true if IMR enabled false if disabled
>+ */
>+static int imr_enabled(struct imr_regs *imr)
Do we want to make it inline perhaps since it is 1 liner?
>+{
>+ return (imr->rmask != IMR_READ_ACCESS_ALL ||
>+ imr->wmask != IMR_WRITE_ACCESS_ALL ||
>+ imr_to_phys(imr->addr_lo) ||
>+ imr_to_phys(imr->addr_hi));
>+}
>+
>+/**
>+ * imr_write - write an IMR at a given index.
>+ *
>+ * Requires caller to hold imr mutex
>+ * Note lock bits need to be written independently of address bits
>+ *
>+ * @imr_id: IMR entry to write
>+ * @imr: IMR structure representing address and access masks
>+ * @lock: indicates if the IMR lock bit should be applied
>+ * @return: 0 on success or error code passed from mbi_iosf on failure
>+ */
>+static int imr_write(u32 imr_id, struct imr_regs *imr, bool lock)
>+{
>+
>+ /* Lock bit must be set separately to addr_lo address bits */
>+ if (lock) {
>+ imr->addr_lo |= IMR_LOCK;
>+ ret = iosf_mbi_write(QRK_MBI_UNIT_MM,
>QRK_MBI_MM_WRITE,
>+ reg - IMR_LOCK_OFF, imr->addr_lo);
>+ }
>+
A bug ...
We should take ret from above into consideration and not assume it always ret=0
below
>+ local_irq_restore(flags);
>+ return 0;
>+done:
>+ /*
>+ * If writing to the IOSF failed then we're in an unknown state,
>+ * likely a very bad state. An IMR in an invalid state will almost
>+ * certainly lead to a memory access violation.
>+ */
>+ local_irq_restore(flags);
>+ WARN(ret, "IOSF-MBI write fail range 0x%08x-0x%08x unreliable\n",
>+ imr_to_phys(imr->addr_lo),
>+ imr_to_phys(imr->addr_hi) + IMR_MASK);
>+
>+ return ret;
>+}
>+
>+
>+/**
>+ * imr_fixup_size - account for the IMR_ALIGN bytes that addr_hi appends
>+ *
>+ * IMR addr_hi has a built in offset of plus IMR_ALIGN (0x400) bytes from the
>+ * value in the register. We need to subtract IMR_ALIGN bytes from input sizes
>+ * as a result
>+ *
>+ * @size: input size bytes
>+ * @return: reduced size
>+ */
>+static unsigned long imr_fixup_size(unsigned long size)
We can make it inline perhaps since it is 1 liner ?
>+{
>+ return size - IMR_ALIGN;
>+}
>+
>+/**
>+ * imr_address_overlap - detects an address overlap
>+ *
>+ * @addr: address to check against an existing IMR
>+ * @imr: imr being checked
>+ * @return: true for overlap false for no overlap
>+ */
Inline?
>+static int imr_address_overlap(unsigned long addr, struct imr_regs *imr)
>+{
>+ return addr >= imr_to_phys(imr->addr_lo) && addr <=
Re: [PATCH] net: dsa/mv88e6352: make mv88e6352_wait generic
On 01/23/2015 03:34 PM, Vivien Didelot wrote: Some busy bits are available in the global register 1, such as the ATU Busy bit. We may want to use this function to wait for them to change, so add a new parameter to mv88e6352_wait() instead of hard-coding REG_GLOBAL2. In the meantime, since the REG_READ() macro already checks for error, remove the redundant check for ret < 0. Signed-off-by: Vivien Didelot Acked-by: Guenter Roeck 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/
[PATCH] net: llc: use correct size for sysctl timeout entries
The timeout entries are sizeof(int) rather than sizeof(long), which
means that when they were getting read we'd also leak kernel memory
to userspace along with the timeout values.
Signed-off-by: Sasha Levin
---
net/llc/sysctl_net_llc.c |8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/net/llc/sysctl_net_llc.c b/net/llc/sysctl_net_llc.c
index 612a5dd..799bafc 100644
--- a/net/llc/sysctl_net_llc.c
+++ b/net/llc/sysctl_net_llc.c
@@ -18,28 +18,28 @@ static struct ctl_table llc2_timeout_table[] = {
{
.procname = "ack",
.data = _llc2_ack_timeout,
- .maxlen = sizeof(long),
+ .maxlen = sizeof(sysctl_llc2_ack_timeout),
.mode = 0644,
.proc_handler = proc_dointvec_jiffies,
},
{
.procname = "busy",
.data = _llc2_busy_timeout,
- .maxlen = sizeof(long),
+ .maxlen = sizeof(sysctl_llc2_busy_timeout),
.mode = 0644,
.proc_handler = proc_dointvec_jiffies,
},
{
.procname = "p",
.data = _llc2_p_timeout,
- .maxlen = sizeof(long),
+ .maxlen = sizeof(sysctl_llc2_p_timeout),
.mode = 0644,
.proc_handler = proc_dointvec_jiffies,
},
{
.procname = "rej",
.data = _llc2_rej_timeout,
- .maxlen = sizeof(long),
+ .maxlen = sizeof(sysctl_llc2_rej_timeout),
.mode = 0644,
.proc_handler = proc_dointvec_jiffies,
},
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/8] ktime: Optimize ktime_divns for constant divisors
From: Nicolas Pitre
At least on ARM, do_div() is optimized to turn constant divisors into
an inline multiplication by the reciprocal value at compile time.
However this optimization is missed entirely whenever ktime_divns() is
used and the slow out-of-line division code is used all the time.
Let ktime_divns() use do_div() inline whenever the divisor is constant
and small enough. This will make things like ktime_to_us() and
ktime_to_ms() much faster.
Cc: Arnd Bergmann
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: Nicolas Pitre
Acked-by: Arnd Bergmann
Signed-off-by: Nicolas Pitre
Signed-off-by: John Stultz
---
include/linux/ktime.h | 12 +++-
kernel/time/hrtimer.c | 4 ++--
2 files changed, 13 insertions(+), 3 deletions(-)
diff --git a/include/linux/ktime.h b/include/linux/ktime.h
index c9d645a..411dd8b 100644
--- a/include/linux/ktime.h
+++ b/include/linux/ktime.h
@@ -166,7 +166,17 @@ static inline bool ktime_before(const ktime_t cmp1, const
ktime_t cmp2)
}
#if BITS_PER_LONG < 64
-extern u64 ktime_divns(const ktime_t kt, s64 div);
+extern u64 __ktime_divns(const ktime_t kt, s64 div);
+static inline u64 ktime_divns(const ktime_t kt, s64 div)
+{
+ if (__builtin_constant_p(div) && !(div >> 32)) {
+ u64 ns = kt.tv64;
+ do_div(ns, div);
+ return ns;
+ } else {
+ return __ktime_divns(kt, div);
+ }
+}
#else /* BITS_PER_LONG < 64 */
# define ktime_divns(kt, div) (u64)((kt).tv64 / (div))
#endif
diff --git a/kernel/time/hrtimer.c b/kernel/time/hrtimer.c
index 37e50aa..890535c 100644
--- a/kernel/time/hrtimer.c
+++ b/kernel/time/hrtimer.c
@@ -266,7 +266,7 @@ lock_hrtimer_base(const struct hrtimer *timer, unsigned
long *flags)
/*
* Divide a ktime value by a nanosecond value
*/
-u64 ktime_divns(const ktime_t kt, s64 div)
+u64 __ktime_divns(const ktime_t kt, s64 div)
{
u64 dclc;
int sft = 0;
@@ -282,7 +282,7 @@ u64 ktime_divns(const ktime_t kt, s64 div)
return dclc;
}
-EXPORT_SYMBOL_GPL(ktime_divns);
+EXPORT_SYMBOL_GPL(__ktime_divns);
#endif /* BITS_PER_LONG >= 64 */
/*
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 8/8] rtc: Convert rtc_set_ntp_time() to use timespec64
From: Xunlei Pang
rtc_set_ntp_time() uses timespec which is y2038-unsafe,
so modify to use timespec64 which is y2038-safe, then
replace rtc_time_to_tm() with rtc_time64_to_tm().
Also adjust all its call sites(only NTP uses it) accordingly.
Cc: pang.xunlei
Cc: Arnd Bergmann
Cc: Thomas Gleixner
Cc: Ingo Molnar
Signed-off-by: Xunlei Pang
Signed-off-by: John Stultz
---
drivers/rtc/systohc.c | 6 +++---
include/linux/rtc.h | 2 +-
kernel/time/ntp.c | 4 ++--
3 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/rtc/systohc.c b/drivers/rtc/systohc.c
index bf3e242..eb71872 100644
--- a/drivers/rtc/systohc.c
+++ b/drivers/rtc/systohc.c
@@ -20,16 +20,16 @@
*
* If temporary failure is indicated the caller should try again 'soon'
*/
-int rtc_set_ntp_time(struct timespec now)
+int rtc_set_ntp_time(struct timespec64 now)
{
struct rtc_device *rtc;
struct rtc_time tm;
int err = -ENODEV;
if (now.tv_nsec < (NSEC_PER_SEC >> 1))
- rtc_time_to_tm(now.tv_sec, );
+ rtc_time64_to_tm(now.tv_sec, );
else
- rtc_time_to_tm(now.tv_sec + 1, );
+ rtc_time64_to_tm(now.tv_sec + 1, );
rtc = rtc_class_open(CONFIG_RTC_HCTOSYS_DEVICE);
if (rtc) {
diff --git a/include/linux/rtc.h b/include/linux/rtc.h
index 6d6be09..dcad7ee 100644
--- a/include/linux/rtc.h
+++ b/include/linux/rtc.h
@@ -161,7 +161,7 @@ extern void devm_rtc_device_unregister(struct device *dev,
extern int rtc_read_time(struct rtc_device *rtc, struct rtc_time *tm);
extern int rtc_set_time(struct rtc_device *rtc, struct rtc_time *tm);
extern int rtc_set_mmss(struct rtc_device *rtc, unsigned long secs);
-extern int rtc_set_ntp_time(struct timespec now);
+extern int rtc_set_ntp_time(struct timespec64 now);
int __rtc_read_alarm(struct rtc_device *rtc, struct rtc_wkalrm *alarm);
extern int rtc_read_alarm(struct rtc_device *rtc,
struct rtc_wkalrm *alrm);
diff --git a/kernel/time/ntp.c b/kernel/time/ntp.c
index 87a346f..183dfe2 100644
--- a/kernel/time/ntp.c
+++ b/kernel/time/ntp.c
@@ -488,13 +488,13 @@ static void sync_cmos_clock(struct work_struct *work)
getnstimeofday64();
if (abs(now.tv_nsec - (NSEC_PER_SEC / 2)) <= tick_nsec * 5) {
- struct timespec adjust = timespec64_to_timespec(now);
+ struct timespec64 adjust = now;
fail = -ENODEV;
if (persistent_clock_is_local)
adjust.tv_sec -= (sys_tz.tz_minuteswest * 60);
#ifdef CONFIG_GENERIC_CMOS_UPDATE
- fail = update_persistent_clock(adjust);
+ fail = update_persistent_clock(timespec64_to_timespec(adjust));
#endif
#ifdef CONFIG_RTC_SYSTOHC
if (fail == -ENODEV)
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 5/8] rtc: Update rtc-dev to use y2038-safe time interfaces
From: Xunlei Pang
Currently, rtc-dev.c uses y2038 problematic rtc_tm_to_time()
and rtc_time_to_tm(). So replace them with their corresponding
y2038-safe versions: rtc_tm_to_time64() and rtc_time64_to_tm().
Cc: pang.xunlei
Cc: Arnd Bergmann
Cc: Thomas Gleixner
Cc: Ingo Molnar
Signed-off-by: Xunlei Pang
Signed-off-by: John Stultz
---
drivers/rtc/rtc-dev.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/rtc/rtc-dev.c b/drivers/rtc/rtc-dev.c
index d049393..799c34b 100644
--- a/drivers/rtc/rtc-dev.c
+++ b/drivers/rtc/rtc-dev.c
@@ -304,12 +304,12 @@ static long rtc_dev_ioctl(struct file *file,
* Not supported here.
*/
{
- unsigned long now, then;
+ time64_t now, then;
err = rtc_read_time(rtc, );
if (err < 0)
return err;
- rtc_tm_to_time(, );
+ now = rtc_tm_to_time64();
alarm.time.tm_mday = tm.tm_mday;
alarm.time.tm_mon = tm.tm_mon;
@@ -317,11 +317,11 @@ static long rtc_dev_ioctl(struct file *file,
err = rtc_valid_tm();
if (err < 0)
return err;
- rtc_tm_to_time(, );
+ then = rtc_tm_to_time64();
/* alarm may need to wrap into tomorrow */
if (then < now) {
- rtc_time_to_tm(now + 24 * 60 * 60, );
+ rtc_time64_to_tm(now + 24 * 60 * 60, );
alarm.time.tm_mday = tm.tm_mday;
alarm.time.tm_mon = tm.tm_mon;
alarm.time.tm_year = tm.tm_year;
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/8] rtc: Update interface.c to use y2038-safe time interfaces
From: Xunlei Pang
Currently, interface.c uses y2038 problematic rtc_tm_to_time()
and rtc_time_to_tm(). So replace them with their corresponding
y2038-safe versions: rtc_tm_to_time64() and rtc_time64_to_tm().
Cc: pang.xunlei
Cc: Arnd Bergmann
Cc: Thomas Gleixner
Cc: Ingo Molnar
Signed-off-by: Xunlei Pang
Signed-off-by: John Stultz
---
drivers/rtc/interface.c | 22 ++
1 file changed, 10 insertions(+), 12 deletions(-)
diff --git a/drivers/rtc/interface.c b/drivers/rtc/interface.c
index 45bfc28ee..37215cf 100644
--- a/drivers/rtc/interface.c
+++ b/drivers/rtc/interface.c
@@ -73,10 +73,8 @@ int rtc_set_time(struct rtc_device *rtc, struct rtc_time *tm)
else if (rtc->ops->set_time)
err = rtc->ops->set_time(rtc->dev.parent, tm);
else if (rtc->ops->set_mmss) {
- unsigned long secs;
- err = rtc_tm_to_time(tm, );
- if (err == 0)
- err = rtc->ops->set_mmss(rtc->dev.parent, secs);
+ time64_t secs64 = rtc_tm_to_time64(tm);
+ err = rtc->ops->set_mmss(rtc->dev.parent, secs64);
} else
err = -EINVAL;
@@ -105,7 +103,7 @@ int rtc_set_mmss(struct rtc_device *rtc, unsigned long secs)
err = rtc->ops->read_time(rtc->dev.parent, );
if (err == 0) {
- rtc_time_to_tm(secs, );
+ rtc_time64_to_tm(secs, );
/*
* avoid writing when we're going to change the day of
@@ -157,7 +155,7 @@ int __rtc_read_alarm(struct rtc_device *rtc, struct
rtc_wkalrm *alarm)
int err;
struct rtc_time before, now;
int first_time = 1;
- unsigned long t_now, t_alm;
+ time64_t t_now, t_alm;
enum { none, day, month, year } missing = none;
unsigned days;
@@ -258,8 +256,8 @@ int __rtc_read_alarm(struct rtc_device *rtc, struct
rtc_wkalrm *alarm)
}
/* with luck, no rollover is needed */
- rtc_tm_to_time(, _now);
- rtc_tm_to_time(>time, _alm);
+ t_now = rtc_tm_to_time64();
+ t_alm = rtc_tm_to_time64(>time);
if (t_now < t_alm)
goto done;
@@ -273,7 +271,7 @@ int __rtc_read_alarm(struct rtc_device *rtc, struct
rtc_wkalrm *alarm)
case day:
dev_dbg(>dev, "alarm rollover: %s\n", "day");
t_alm += 24 * 60 * 60;
- rtc_time_to_tm(t_alm, >time);
+ rtc_time64_to_tm(t_alm, >time);
break;
/* Month rollover ... if it's the 31th, an alarm on the 3rd will
@@ -346,19 +344,19 @@ EXPORT_SYMBOL_GPL(rtc_read_alarm);
static int __rtc_set_alarm(struct rtc_device *rtc, struct rtc_wkalrm *alarm)
{
struct rtc_time tm;
- long now, scheduled;
+ time64_t now, scheduled;
int err;
err = rtc_valid_tm(>time);
if (err)
return err;
- rtc_tm_to_time(>time, );
+ scheduled = rtc_tm_to_time64(>time);
/* Make sure we're not setting alarms in the past */
err = __rtc_read_time(rtc, );
if (err)
return err;
- rtc_tm_to_time(, );
+ now = rtc_tm_to_time64();
if (scheduled <= now)
return -ETIME;
/*
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 6/8] rtc: Modify rtc_hctosys() to address y2038 issues
From: Xunlei Pang
rtc_hctosys() has a number of y2038 issues.
This patch resolves them by:
- Replace rtc_tm_to_time() with y2038-safe rtc_tm_to_time64()
- Replace do_settimeofday() with y2038-safe do_settimeofday64()
After this patch, it should not have any remaining y2038 issues.
Cc: pang.xunlei
Cc: Arnd Bergmann
Cc: Thomas Gleixner
Cc: Ingo Molnar
Signed-off-by: Xunlei Pang
Signed-off-by: John Stultz
---
drivers/rtc/hctosys.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/rtc/hctosys.c b/drivers/rtc/hctosys.c
index 4aa60d7..2153b52 100644
--- a/drivers/rtc/hctosys.c
+++ b/drivers/rtc/hctosys.c
@@ -26,7 +26,7 @@ static int __init rtc_hctosys(void)
{
int err = -ENODEV;
struct rtc_time tm;
- struct timespec tv = {
+ struct timespec64 tv64 = {
.tv_nsec = NSEC_PER_SEC >> 1,
};
struct rtc_device *rtc = rtc_class_open(CONFIG_RTC_HCTOSYS_DEVICE);
@@ -52,16 +52,16 @@ static int __init rtc_hctosys(void)
goto err_invalid;
}
- rtc_tm_to_time(, _sec);
+ tv64.tv_sec = rtc_tm_to_time64();
- err = do_settimeofday();
+ err = do_settimeofday64();
dev_info(rtc->dev.parent,
"setting system clock to "
- "%d-%02d-%02d %02d:%02d:%02d UTC (%u)\n",
+ "%d-%02d-%02d %02d:%02d:%02d UTC (%lld)\n",
tm.tm_year + 1900, tm.tm_mon + 1, tm.tm_mday,
tm.tm_hour, tm.tm_min, tm.tm_sec,
- (unsigned int) tv.tv_sec);
+ (long long) tv64.tv_sec);
err_invalid:
err_read:
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 7/8] rtc: Remove redundant rtc_valid_tm() from rtc_hctosys()
From: Xunlei Pang
rtc_read_time() has already judged valid tm by rtc_valid_tm(),
so just remove it.
Cc: pang.xunlei
Cc: Arnd Bergmann
Cc: Thomas Gleixner
Cc: Ingo Molnar
Signed-off-by: Xunlei Pang
Signed-off-by: John Stultz
---
drivers/rtc/hctosys.c | 8
1 file changed, 8 deletions(-)
diff --git a/drivers/rtc/hctosys.c b/drivers/rtc/hctosys.c
index 2153b52..6c719f2 100644
--- a/drivers/rtc/hctosys.c
+++ b/drivers/rtc/hctosys.c
@@ -45,13 +45,6 @@ static int __init rtc_hctosys(void)
}
- err = rtc_valid_tm();
- if (err) {
- dev_err(rtc->dev.parent,
- "hctosys: invalid date/time\n");
- goto err_invalid;
- }
-
tv64.tv_sec = rtc_tm_to_time64();
err = do_settimeofday64();
@@ -63,7 +56,6 @@ static int __init rtc_hctosys(void)
tm.tm_hour, tm.tm_min, tm.tm_sec,
(long long) tv64.tv_sec);
-err_invalid:
err_read:
rtc_class_close(rtc);
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/8] time: Expose get_monotonic_boottime64 for in-kernel use
As part of the 2038 conversion process, add a
get_monotonic_boottime64 accessor so we can depracate
get_monotonic_boottime.
Cc: pang.xunlei
Cc: Arnd Bergmann
Cc: Thomas Gleixner
Cc: Ingo Molnar
Signed-off-by: John Stultz
---
include/linux/timekeeping.h | 5 +
1 file changed, 5 insertions(+)
diff --git a/include/linux/timekeeping.h b/include/linux/timekeeping.h
index 9148013..3eaae47 100644
--- a/include/linux/timekeeping.h
+++ b/include/linux/timekeeping.h
@@ -229,6 +229,11 @@ static inline void get_monotonic_boottime(struct timespec
*ts)
*ts = ktime_to_timespec(ktime_get_boottime());
}
+static inline void get_monotonic_boottime64(struct timespec64 *ts)
+{
+ *ts = ktime_to_timespec64(ktime_get_boottime());
+}
+
static inline void timekeeping_clocktai(struct timespec *ts)
{
*ts = ktime_to_timespec(ktime_get_clocktai());
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] Time items for 3.20
Hey Thomas, Ingo, Just wanted to send out my current 3.20 queue so it can get some time in -next. Let me know if you have any objections or concerns. thanks -john Cc: pang.xunlei Cc: Arnd Bergmann Cc: Thomas Gleixner Cc: Ingo Molnar Cc: Nicolas Pitre The following changes since commit eaa27f34e91a14cdceed26ed6c6793ec1d186115: linux 3.19-rc4 (2015-01-11 12:44:53 -0800) are available in the git repository at: https://git.linaro.org/people/john.stultz/linux.git tags/fortglx-3.20-time for you to fetch changes up to 9a4a445e30f0b601ca2d9433274047cbf48ebf9e: rtc: Convert rtc_set_ntp_time() to use timespec64 (2015-01-23 17:21:57 -0800) Couple of items for 3.20 * ktime division optimization * Expose a few more y2038-safe timekeeping interfaces * RTC core changes to address y2038 Signed-off-by: John Stultz John Stultz (2): time: Expose getboottime64 for in-kernel uses time: Expose get_monotonic_boottime64 for in-kernel use Nicolas Pitre (1): ktime: Optimize ktime_divns for constant divisors Xunlei Pang (5): rtc: Update interface.c to use y2038-safe time interfaces rtc: Update rtc-dev to use y2038-safe time interfaces rtc: Modify rtc_hctosys() to address y2038 issues rtc: Remove redundant rtc_valid_tm() from rtc_hctosys() rtc: Convert rtc_set_ntp_time() to use timespec64 drivers/rtc/hctosys.c | 18 +- drivers/rtc/interface.c | 22 ++ drivers/rtc/rtc-dev.c | 8 drivers/rtc/systohc.c | 6 +++--- include/linux/ktime.h | 12 +++- include/linux/rtc.h | 2 +- include/linux/timekeeping.h | 21 +++-- kernel/time/hrtimer.c | 4 ++-- kernel/time/ntp.c | 4 ++-- kernel/time/timekeeping.c | 12 ++-- 10 files changed, 63 insertions(+), 46 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 2/8] time: Expose getboottime64 for in-kernel uses
Adds a timespec64 based getboottime64() implementation
that can be used as we convert internal users of
getboottime away from using timespecs.
Cc: pang.xunlei
Cc: Arnd Bergmann
Cc: Thomas Gleixner
Cc: Ingo Molnar
Signed-off-by: John Stultz
---
include/linux/timekeeping.h | 16 ++--
kernel/time/timekeeping.c | 12 ++--
2 files changed, 20 insertions(+), 8 deletions(-)
diff --git a/include/linux/timekeeping.h b/include/linux/timekeeping.h
index 9b63d13..9148013 100644
--- a/include/linux/timekeeping.h
+++ b/include/linux/timekeeping.h
@@ -33,6 +33,7 @@ extern time64_t ktime_get_real_seconds(void);
extern int __getnstimeofday64(struct timespec64 *tv);
extern void getnstimeofday64(struct timespec64 *tv);
+extern void getboottime64(struct timespec64 *ts);
#if BITS_PER_LONG == 64
/**
@@ -72,6 +73,11 @@ static inline struct timespec get_monotonic_coarse(void)
{
return get_monotonic_coarse64();
}
+
+static inline void getboottime(struct timespec *ts)
+{
+ return getboottime64(ts);
+}
#else
/**
* Deprecated. Use do_settimeofday64().
@@ -129,9 +135,15 @@ static inline struct timespec get_monotonic_coarse(void)
{
return timespec64_to_timespec(get_monotonic_coarse64());
}
-#endif
-extern void getboottime(struct timespec *ts);
+static inline void getboottime(struct timespec *ts)
+{
+ struct timespec64 ts64;
+
+ getboottime64();
+ *ts = timespec64_to_timespec(ts64);
+}
+#endif
#define do_posix_clock_monotonic_gettime(ts) ktime_get_ts(ts)
#define ktime_get_real_ts64(ts)getnstimeofday64(ts)
diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c
index 6a93185..b124af2 100644
--- a/kernel/time/timekeeping.c
+++ b/kernel/time/timekeeping.c
@@ -1659,24 +1659,24 @@ out:
}
/**
- * getboottime - Return the real time of system boot.
- * @ts:pointer to the timespec to be set
+ * getboottime64 - Return the real time of system boot.
+ * @ts:pointer to the timespec64 to be set
*
- * Returns the wall-time of boot in a timespec.
+ * Returns the wall-time of boot in a timespec64.
*
* This is based on the wall_to_monotonic offset and the total suspend
* time. Calls to settimeofday will affect the value returned (which
* basically means that however wrong your real time clock is at boot time,
* you get the right time here).
*/
-void getboottime(struct timespec *ts)
+void getboottime64(struct timespec64 *ts)
{
struct timekeeper *tk = _core.timekeeper;
ktime_t t = ktime_sub(tk->offs_real, tk->offs_boot);
- *ts = ktime_to_timespec(t);
+ *ts = ktime_to_timespec64(t);
}
-EXPORT_SYMBOL_GPL(getboottime);
+EXPORT_SYMBOL_GPL(getboottime64);
unsigned long get_seconds(void)
{
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
perf: NULL ptr deref in perf_event_mmap, d_path
Hi all, While fuzzing with trinity inside a KVM tools guest running the latest -next kernel and the KASan patchset, I've stumbled on the following spew: [ 549.058124] general protection fault: [#1] PREEMPT SMP KASAN [ 549.060152] Dumping ftrace buffer: [ 549.060219](ftrace buffer empty) [ 549.062191] Modules linked in: [ 549.062191] CPU: 19 PID: 16330 Comm: modprobe Not tainted 3.19.0-rc5-next-20150123-sasha-00061-g527ff0d-dirty #1813 [ 549.062191] task: 88039962 ti: 88039bec task.ti: 88039bec [ 549.062191] RIP: prepend_path (fs/dcache.c:2864) [ 549.062191] RSP: 0018:88039bec7748 EFLAGS: 00010202 [ 549.062191] RAX: 0004 RBX: RCX: 11003733 [ 549.062191] RDX: 88003deb79c0 RSI: 88039bec7858 RDI: 88003deb4eb0 [ 549.062191] RBP: 88039bec7908 R08: dc00 R09: [ 549.062191] R10: 88039bec7648 R11: 0004 R12: 0020 [ 549.062191] R13: R14: dc00 R15: 88039bec79c8 [ 549.062191] FS: () GS:8805f880() knlGS: [ 549.062191] CS: 0010 DS: ES: CR0: 8005003b [ 549.062191] CR2: 7f8a3989d4a0 CR3: 0006b1a55000 CR4: 06a0 [ 549.062191] DR0: a8001000 DR1: DR2: [ 549.062191] DR3: DR6: 0ff0 DR7: 0600 [ 549.062191] Stack: [ 549.062191] 81c35e2b 880399620cf0 41b58ab3 95ab8e78 [ 549.062191] 88039bec79d0 1100737d8ef7 8805da69b758 ed00737d8f39 [ 549.062191] 88039bec7964 88039bec7988 8805da69b750 ed00737d8f3a [ 549.062191] Call Trace: [ 549.111668] d_path (fs/dcache.c:2987 fs/dcache.c:3044) [ 549.111668] perf_event_mmap (kernel/events/core.c:5435 kernel/events/core.c:5560) [ 549.111668] mmap_region (mm/mmap.c:1207 mm/mmap.c:1650) [ 549.111668] do_mmap_pgoff (mm/mmap.c:1393) [ 549.111668] vm_mmap_pgoff (mm/util.c:335) [ 549.111668] SyS_mmap_pgoff (mm/mmap.c:1443 mm/mmap.c:1401) [ 549.111668] SyS_mmap (arch/x86/kernel/sys_x86_64.c:70) [ 549.111668] tracesys_phase2 (arch/x86/kernel/entry_64.S:530) [ 549.111668] Code: c7 07 0f 85 cc 00 00 00 48 39 d3 0f 84 cc 01 00 00 4d 85 e4 0f 84 90 08 00 00 41 f6 c4 07 0f 85 86 08 00 00 4c 89 e0 48 c1 e8 03 <42> 80 3c 30 00 0f 85 96 08 00 00 49 3b 1c 24 0f 84 2d 01 00 00 All code 0: c7 07 0f 85 cc 00 movl $0xcc850f,(%rdi) 6: 00 00 add%al,(%rax) 8: 48 39 d3cmp%rdx,%rbx b: 0f 84 cc 01 00 00 je 0x1dd 11: 4d 85 e4test %r12,%r12 14: 0f 84 90 08 00 00 je 0x8aa 1a: 41 f6 c4 07 test $0x7,%r12b 1e: 0f 85 86 08 00 00 jne0x8aa 24: 4c 89 e0mov%r12,%rax 27: 48 c1 e8 03 shr$0x3,%rax 2b:* 42 80 3c 30 00 cmpb $0x0,(%rax,%r14,1) <-- trapping instruction 30: 0f 85 96 08 00 00 jne0x8cc 36: 49 3b 1c 24 cmp(%r12),%rbx 3a: 0f 84 2d 01 00 00 je 0x16d ... Code starting with the faulting instruction === 0: 42 80 3c 30 00 cmpb $0x0,(%rax,%r14,1) 5: 0f 85 96 08 00 00 jne0x8a1 b: 49 3b 1c 24 cmp(%r12),%rbx f: 0f 84 2d 01 00 00 je 0x142 ... [ 549.111668] RIP prepend_path (fs/dcache.c:2864) [ 549.111668] RSP Thanks, Sasha -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv2] char:ipmi: Free ipmi_recv_msg messages from the linked list,recv_msgs for the function,ipmi_release in the file,ipmi_devintf.c
On 01/23/2015 02:00 PM, Corey Minyard wrote: > On 01/23/2015 12:27 PM, nick wrote: >> > Corney, >> > Hope this patch fixes the issue. Sorry about missing that kfree >> > being required. :( > Well, the kfree needs to be after the free of the messages.You can't > use an item after you free it. As you can see, his patches aren't event tested. See https://lkml.org/lkml/2014/8/4/206 . Thanks, Sasha -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] modsign: overwrite keys with zero before deleting them
On 24/01/15 00:13, Alexander Holler wrote: > Am 24.01.2015 um 00:58 schrieb David Howells: >> Alexander Holler wrote: >> >>> This is for the more paranoid people, also it's >>> questionable what paranoid nowadays means. >> >> shred? > > Seems to do the same like when using dd, just that it does it moultiple > times. > > And according to an article I've read some years ago, overwrriting a > blocks on harddisks multiple times doesn't really make sense because > doing it just once is enough (the necessity to do it multiple times > seems to have been one of these unexplainable myths in the IT) . > > So I've no idea if it's worth to use shred and have no idea if it's part > of any GNU/Linux system (seems likely as it it's part of coreutils), how > it's maintained and how long it will be available. > > But if requested, I will replace that dd with shred or just feel free to > do it yourself. shred is in the same package as dd (coreutils). It's a bit more paranoid about syncing. It also tries to write the exact size of the file, and then rounded up block sizes to decrease the chance of file system reallocation. Agreed on the multiple writes being quite futile these days. Generally overwriting with dd or shred etc. is only useful at the device level rather than at the file system level. Anyway to be slightly more paranoid and explicit you could: shred -n1 ./signing_key.priv Pádraig. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 2/5] x86, traps: Track entry into and exit from IST context
On Fri, Jan 23, 2015 at 12:48 PM, Sasha Levin wrote: > On 01/23/2015 01:34 PM, Andy Lutomirski wrote: >> On Fri, Jan 23, 2015 at 10:04 AM, Borislav Petkov wrote: >>> On Fri, Jan 23, 2015 at 09:58:01AM -0800, Andy Lutomirski wrote: > [ 543.999079] Call Trace: > [ 543.999079] dump_stack (lib/dump_stack.c:52) > [ 543.999079] lockdep_rcu_suspicious (kernel/locking/lockdep.c:4259) > [ 543.999079] atomic_notifier_call_chain (include/linux/rcupdate.h:892 > kernel/notifier.c:182 kernel/notifier.c:193) > [ 543.999079] ? atomic_notifier_call_chain (kernel/notifier.c:192) > [ 543.999079] notify_die (kernel/notifier.c:538) > [ 543.999079] ? atomic_notifier_call_chain (kernel/notifier.c:538) > [ 543.999079] ? debug_smp_processor_id (lib/smp_processor_id.c:57) > [ 543.999079] do_debug (arch/x86/kernel/traps.c:652) > [ 543.999079] ? trace_hardirqs_on (kernel/locking/lockdep.c:2609) > [ 543.999079] ? do_int3 (arch/x86/kernel/traps.c:610) > [ 543.999079] ? trace_hardirqs_on_caller (kernel/locking/lockdep.c:2554 > kernel/locking/lockdep.c:2601) > [ 543.999079] debug (arch/x86/kernel/entry_64.S:1310) I don't know how to read this stack trace. Are we in do_int3, do_debug, or both? I didn't change do_debug at all. >>> >>> It looks like we're in do_debug. do_int3 is only on the stack but not >>> part of the current frame if I can trust the '?' ... >>> >> >> It's possible that an int3 happened and I did something wrong on >> return that caused a subsequent do_debug to screw up, but I don't see >> how my patch would have caused that. >> >> Were there any earlier log messages? > > Nope, nothing odd before or after. Trinity just survived for a decent amount of time for me with my patches, other than a bunch of apparently expected OOM kills. I have no idea how to tell trinity how much memory to use. --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 v2 2/2] leds: add Qualcomm PM8941 WLED driver
On Fri, Jan 23, 2015 at 4:54 PM, Bjorn Andersson
wrote:
> From: Courtney Cavin
>
> This adds support for the WLED ('White' LED) block on Qualcomm's
> PM8941 PMICs.
>
> Signed-off-by: Courtney Cavin
> Signed-off-by: Bjorn Andersson
> ---
Sorry, I missed the change log.
Changed since v1:
* Replace enum blob with defines
* Merged wled_context and wled structs
* Some style updates
Regards,
Bjorn
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH 2/2] fbcon: expose cursor blink interval via sysfs
The fbcon cursor, when set to blink, is hardcoded to toggle display state
five times per second. Expose this setting via
/sys/class/graphics/fbcon/cursor_blink_ms
Values written to the interface set the approximate time interval in
milliseconds between cursor toggles, from 1 to 32767. Since the interval
is stored internally as a number of jiffies, the millisecond value read
from the interface may not exactly match the entered value.
An outstanding blink timer is reset after a new value is entered.
If the cursor blink is disabled, either via the 'cursor_blink' boolean
setting or some other mechanism, the 'cursor_blink_ms' setting may still
be modified. The new value will be used if the blink is reactivated.
Tested with intelfb.
Signed-off-by: Scot Doyle
---
drivers/video/console/fbcon.c | 75 +++
1 file changed, 75 insertions(+)
diff --git a/drivers/video/console/fbcon.c b/drivers/video/console/fbcon.c
index 7a2030b..0ddfcf6 100644
--- a/drivers/video/console/fbcon.c
+++ b/drivers/video/console/fbcon.c
@@ -3495,11 +3495,86 @@ err:
return count;
}
+static ssize_t show_cursor_blink_ms(struct device *device,
+ struct device_attribute *attr, char *buf)
+{
+ struct fb_info *info;
+ struct fbcon_ops *ops;
+ int idx, ms = -1;
+
+ if (fbcon_has_exited)
+ return 0;
+
+ console_lock();
+ idx = con2fb_map[fg_console];
+
+ if (idx == -1 || registered_fb[idx] == NULL)
+ goto err;
+
+ info = registered_fb[idx];
+ ops = info->fbcon_par;
+
+ if (!ops)
+ goto err;
+
+ ms = jiffies_to_msecs(ops->blink_jiffies);
+
+err:
+ console_unlock();
+ return snprintf(buf, PAGE_SIZE, "%d\n", ms);
+}
+
+static ssize_t store_cursor_blink_ms(struct device *device,
+struct device_attribute *attr,
+const char *buf, size_t count)
+{
+ struct fb_info *info;
+ struct fbcon_ops *ops;
+ int idx;
+ unsigned long ms;
+
+ if (fbcon_has_exited)
+ return count;
+
+ console_lock();
+ idx = con2fb_map[fg_console];
+
+ if (idx == -1 || registered_fb[idx] == NULL)
+ goto err;
+
+ info = registered_fb[idx];
+
+ if (!info->fbcon_par)
+ goto err;
+
+ ops = info->fbcon_par;
+
+ if (!ops)
+ goto err;
+
+ if (!kstrtoul(buf, 0, )) {
+ ms = min_t(unsigned long, ms, SHRT_MAX);
+ ops->blink_jiffies = max_t(int, msecs_to_jiffies(ms), 1);
+
+ if (info->queue.func == fb_flashcursor &&
+ ops->flags & FBCON_FLAGS_CURSOR_TIMER) {
+ fbcon_del_cursor_timer(info);
+ fbcon_add_cursor_timer(info);
+ }
+ }
+
+err:
+ console_unlock();
+ return count;
+}
+
static struct device_attribute device_attrs[] = {
__ATTR(rotate, S_IRUGO|S_IWUSR, show_rotate, store_rotate),
__ATTR(rotate_all, S_IWUSR, NULL, store_rotate_all),
__ATTR(cursor_blink, S_IRUGO|S_IWUSR, show_cursor_blink,
store_cursor_blink),
+ __ATTR(cursor_blink_ms, S_IRUGO|S_IWUSR, show_cursor_blink_ms,
+ store_cursor_blink_ms),
};
static int fbcon_init_device(void)
--
2.1.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/
[RFC PATCH 1/2] fbcon: store cursor blink interval in fbcon_ops
The fbcon cursor, when set to blink, is hardcoded to toggle display state
five times per second. Move this setting to a the driver's fbdev_ops
structure, retaining the default blink interval.
Signed-off-by: Scot Doyle
---
drivers/video/console/fbcon.c | 5 +++--
drivers/video/console/fbcon.h | 1 +
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/video/console/fbcon.c b/drivers/video/console/fbcon.c
index ea43724..7a2030b 100644
--- a/drivers/video/console/fbcon.c
+++ b/drivers/video/console/fbcon.c
@@ -405,7 +405,7 @@ static void cursor_timer_handler(unsigned long dev_addr)
struct fbcon_ops *ops = info->fbcon_par;
queue_work(system_power_efficient_wq, >queue);
- mod_timer(>cursor_timer, jiffies + HZ/5);
+ mod_timer(>cursor_timer, jiffies + ops->blink_jiffies);
}
static void fbcon_add_cursor_timer(struct fb_info *info)
@@ -420,7 +420,7 @@ static void fbcon_add_cursor_timer(struct fb_info *info)
init_timer(>cursor_timer);
ops->cursor_timer.function = cursor_timer_handler;
- ops->cursor_timer.expires = jiffies + HZ / 5;
+ ops->cursor_timer.expires = jiffies + ops->blink_jiffies;
ops->cursor_timer.data = (unsigned long ) info;
add_timer(>cursor_timer);
ops->flags |= FBCON_FLAGS_CURSOR_TIMER;
@@ -959,6 +959,7 @@ static const char *fbcon_startup(void)
ops->currcon = -1;
ops->graphics = 1;
ops->cur_rotate = -1;
+ ops->blink_jiffies = msecs_to_jiffies(200);
info->fbcon_par = ops;
p->con_rotate = initial_rotation;
set_blitting_type(vc, info);
diff --git a/drivers/video/console/fbcon.h b/drivers/video/console/fbcon.h
index 6bd2e0c..642c4e7 100644
--- a/drivers/video/console/fbcon.h
+++ b/drivers/video/console/fbcon.h
@@ -70,6 +70,7 @@ struct fbcon_ops {
struct fb_cursor cursor_state;
struct display *p;
intcurrcon;/* Current VC. */
+ intblink_jiffies;
intcursor_flash;
intcursor_reset;
intblank_state;
--
2.1.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/
[RFC PATCH 0/2] fbcon: user-defined cursor blink interval
Allow users to set fbcon's cursor blink interval. The current interval of 200 milliseconds is retained as the default. Tested with intelfb. Scot Doyle (2): fbcon: store cursor blink interval in fbcon_ops fbcon: expose cursor blink interval via sysfs drivers/video/console/fbcon.c | 80 +-- drivers/video/console/fbcon.h | 1 + 2 files changed, 79 insertions(+), 2 deletions(-) -- 2.1.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 12/13] ARM: dts: omap3-gta04: uart4 is not connected, so mark it "disabled"
* NeilBrown [150123 14:31]:
> On Thu, 22 Jan 2015 13:40:53 -0800 Tony Lindgren wrote:
> > >
> > > + {
> > > + status = "disabled";
> > > +};
> > > +
> >
> > This you probably want to avoid from PM point of view. Depending on
> > bootloader state of uart4, Linux may or may not be able to hit any
> > deeper power states.
> >
> > Marking something with status = "disabled" in dts causes the device
> > entry not even to be created. That means hwmod won't be able to reset
> > and idle this device during boot.
> >
> > The uart4 device is there for sure even if not muxed and in incomplete
> > state. You may want to also check other places where you're using
> > status = "disabled" for the same reasons.
>
> That's ... unfortunate. Would that apply to the MCBSPs too? They are
> disabled by default so you would need to explicitly enable them all for
> sensible behaviour
Yeah that applies to all the SoC integrated devices that the bus code
(hwmod) is supposed to reset and idle if unused. Basically anything
that depends on the dev entry being created.
> Hopefully there is some way to mark as device as "this is not used, make sure
> it is turned off and stays off" ???
Not currently that I know of :) To do that, we should add something
like status = "incomplete" where the dev entry gets created but the
driver is never probed. And incomplete here meaning that the device
is missing some parts like pins that would make it work properly.
> Thanks for the heads-up. I'll have a look and see exactly what is happening.
OK
> BTW, on the topic of OMAP UARTs and power saving...
> I note that there are now two drivers for the OMAP3 UART - omap-serial and
> 8250_omap.
> I also note that your commit:
>
> commit a2fc36613ac1af2e92cbed7af80bc72d8114dd50
> ARM: OMAP3: Use manual idle for UARTs because of DMA errata
>
> is incompatible with omap-serial. In particular, if I enable runtime
> suspend of the serial port by setting the autosuspend_timeout, then incoming
> characters will no longer wake the port (if I revert your patch incoming
> chars do wake the port).
> This could (I think) be fixed by enabling the RX/CTS interrupt. However if
> omap-serial is being deprecated, then there probably isn't any point.
>
> So: what is the longer term expectation for these drivers? Should we be
> switching over to 8250?
Yeah you should alredy be able to do it. Hopefully we'll have some
translation layer and the old omap-serial.c can be mostly removed
now that we have 8250 support with runtime PM :)
Regards,
Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mm, vmacache: Add kconfig VMACACHE_SHIFT
On 01/23/2015 12:14 AM, WANG Chao wrote: > On 01/22/15 at 11:22am, Rik van Riel wrote: >> > On 01/22/2015 11:19 AM, Davidlohr Bueso wrote: >>> > > On Thu, 2015-01-22 at 15:57 +0800, WANG Chao wrote: > >> Hi, Davidlohr > >> > >> On 01/21/15 at 11:46pm, Davidlohr Bueso wrote: > > >>> On Thu, 2015-01-22 at 14:29 +0800, WANG Chao wrote: >> > Add a new kconfig option VMACACHE_SHIFT (as a power of 2) to >> > specify the >> > number of slots vma cache has for each thread. Range is chosen >> > 0-4 (1-16 >> > slots) to consider both overhead and performance penalty. Default >> > is 2 >> > (4 slots) as it originally is, which provides good enough balance. >> > > > >>> > > >>> Nack. I don't feel comfortable making scalability features of core > > >>> code > > >>> configurable. > >> > >> Out of respect, is this a general rule not making scalability features > >> of core code configurable? >>> > > >>> > > I doubt its a rule, just common sense. Users have no business >>> > > configuring such low level details. The optimizations need to >>> > > transparently work for everyone. >> > >> > There may sometimes be a good reason for making this kind of >> > thing configurable, but since there were no performance >> > numbers in the changelog, I have not seen any such reason for >> > this particular change :) > True. I didn't run any kind of benchmark, thus no numbers here. This is > purely hypothetical. > > I'm glad to run some tests. For the sake of consistency, could you > please show me a hint how do you measure at the first place? I can do > hit-rate, but I don't know how you measure cpu cycles. Could you > elaborate? I don't think there's a need to look for problems where there are none. Have you observed a performance issue that might be improved by changing the shift here? Thanks, Sasha -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 1/2] leds: add DT binding for Qualcomm PM8941 WLED block
From: Courtney Cavin
This adds device tree binding documentation for the WLED ('White' LED)
block on Qualcomm's PM8941 PMICs.
Signed-off-by: Courtney Cavin
Signed-off-by: Bjorn Andersson
---
.../devicetree/bindings/leds/leds-pm8941-wled.txt | 43 ++
1 file changed, 43 insertions(+)
create mode 100644 Documentation/devicetree/bindings/leds/leds-pm8941-wled.txt
diff --git a/Documentation/devicetree/bindings/leds/leds-pm8941-wled.txt
b/Documentation/devicetree/bindings/leds/leds-pm8941-wled.txt
new file mode 100644
index 000..a85a964
--- /dev/null
+++ b/Documentation/devicetree/bindings/leds/leds-pm8941-wled.txt
@@ -0,0 +1,43 @@
+Binding for Qualcomm PM8941 WLED driver
+
+Required properties:
+- compatible: should be "qcom,pm8941-wled"
+- reg: slave address
+
+Optional properties:
+- label: The label for this led
+ See Documentation/devicetree/bindings/leds/common.txt
+- linux,default-trigger: Default trigger assigned to the LED
+ See Documentation/devicetree/bindings/leds/common.txt
+- qcom,cs-out: bool; enable current sink output
+- qcom,cabc: bool; enable content adaptive backlight control
+- qcom,ext-gen: bool; use externally generated modulator signal to dim
+- qcom,current-limit: mA; per-string current limit; value from 0 to 25
+ default: 20mA
+- qcom,current-boost-limit: mA; boost current limit; one of:
+ 105, 385, 525, 805, 980, 1260, 1400, 1680
+ default: 805mA
+- qcom,switching-freq: kHz; switching frequency; one of:
+ 600, 640, 685, 738, 800, 872, 960, 1066, 1200, 1371,
+ 1600, 1920, 2400, 3200, 4800, 9600,
+ default: 1600kHz
+- qcom,ovp: V; Over-voltage protection limit; one of:
+ 27, 29, 32, 35
+ default: 29V
+- qcom,num-strings: #; number of led strings attached; value from 1 to 3
+ default: 2
+
+Example:
+
+pm8941-wled@d800 {
+ compatible = "qcom,pm8941-wled";
+ reg = <0xd800>;
+ label = "backlight";
+
+ qcom,cs-out;
+ qcom,current-limit = <20>;
+ qcom,current-boost-limit = <805>;
+ qcom,switching-freq = <1600>;
+ qcom,ovp = <29>;
+ qcom,num-strings = <2>;
+};
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 2/2] leds: add Qualcomm PM8941 WLED driver
From: Courtney Cavin
This adds support for the WLED ('White' LED) block on Qualcomm's
PM8941 PMICs.
Signed-off-by: Courtney Cavin
Signed-off-by: Bjorn Andersson
---
drivers/leds/Kconfig| 8 +
drivers/leds/Makefile | 1 +
drivers/leds/leds-pm8941-wled.c | 459
3 files changed, 468 insertions(+)
create mode 100644 drivers/leds/leds-pm8941-wled.c
diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
index a6c3d2f..901b21a 100644
--- a/drivers/leds/Kconfig
+++ b/drivers/leds/Kconfig
@@ -516,6 +516,14 @@ config LEDS_VERSATILE
This option enabled support for the LEDs on the ARM Versatile
and RealView boards. Say Y to enabled these.
+config LEDS_PM8941_WLED
+ tristate "LED support for the Qualcomm PM8941 WLED block"
+ depends on LEDS_CLASS
+ select REGMAP
+ help
+ This option enables support for the 'White' LED block
+ on Qualcomm PM8941 PMICs.
+
comment "LED Triggers"
source "drivers/leds/trigger/Kconfig"
diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile
index 1c65a19..4325e49 100644
--- a/drivers/leds/Makefile
+++ b/drivers/leds/Makefile
@@ -57,6 +57,7 @@ obj-$(CONFIG_LEDS_BLINKM) += leds-blinkm.o
obj-$(CONFIG_LEDS_SYSCON) += leds-syscon.o
obj-$(CONFIG_LEDS_VERSATILE) += leds-versatile.o
obj-$(CONFIG_LEDS_MENF21BMC) += leds-menf21bmc.o
+obj-$(CONFIG_LEDS_PM8941_WLED) += leds-pm8941-wled.o
# LED SPI Drivers
obj-$(CONFIG_LEDS_DAC124S085) += leds-dac124s085.o
diff --git a/drivers/leds/leds-pm8941-wled.c b/drivers/leds/leds-pm8941-wled.c
new file mode 100644
index 000..beaa7de
--- /dev/null
+++ b/drivers/leds/leds-pm8941-wled.c
@@ -0,0 +1,459 @@
+/* Copyright (c) 2015, Sony Mobile Communications, AB.
+ *
+ * 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.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define PM8941_WLED_REG_VAL_BASE 0x40
+#define PM8941_WLED_REG_VAL_MAX 0xFFF
+
+#define PM8941_WLED_REG_MOD_EN 0x46
+#define PM8941_WLED_REG_MOD_EN_BITBIT(7)
+#define PM8941_WLED_REG_MOD_EN_MASK BIT(7)
+
+#define PM8941_WLED_REG_SYNC 0x47
+#define PM8941_WLED_REG_SYNC_MASK 0x07
+#define PM8941_WLED_REG_SYNC_LED1 BIT(0)
+#define PM8941_WLED_REG_SYNC_LED2 BIT(1)
+#define PM8941_WLED_REG_SYNC_LED3 BIT(2)
+#define PM8941_WLED_REG_SYNC_ALL 0x07
+#define PM8941_WLED_REG_SYNC_CLEAR0x00
+
+#define PM8941_WLED_REG_FREQ 0x4c
+#define PM8941_WLED_REG_FREQ_MASK 0x0f
+
+#define PM8941_WLED_REG_OVP0x4d
+#define PM8941_WLED_REG_OVP_MASK 0x03
+
+#define PM8941_WLED_REG_BOOST 0x4e
+#define PM8941_WLED_REG_BOOST_MASK0x07
+
+#define PM8941_WLED_REG_SINK 0x4f
+#define PM8941_WLED_REG_SINK_MASK 0xe0
+#define PM8941_WLED_REG_SINK_SHFT 0x05
+
+/* Per-'string' registers below */
+#define PM8941_WLED_REG_STR_OFFSET 0x10
+
+#define PM8941_WLED_REG_STR_MOD_EN_BASE0x60
+#define PM8941_WLED_REG_STR_MOD_MASK BIT(7)
+#define PM8941_WLED_REG_STR_MOD_ENBIT(7)
+
+#define PM8941_WLED_REG_STR_SCALE_BASE 0x62
+#define PM8941_WLED_REG_STR_SCALE_MASK0x1f
+
+#define PM8941_WLED_REG_STR_MOD_SRC_BASE 0x63
+#define PM8941_WLED_REG_STR_MOD_SRC_MASK 0x01
+#define PM8941_WLED_REG_STR_MOD_SRC_INT 0x00
+#define PM8941_WLED_REG_STR_MOD_SRC_EXT 0x01
+
+#define PM8941_WLED_REG_STR_CABC_BASE 0x66
+#define PM8941_WLED_REG_STR_CABC_MASK BIT(7)
+#define PM8941_WLED_REG_STR_CABC_EN BIT(7)
+
+struct pm8941_wled_config {
+ u32 i_boost_limit;
+ u32 ovp;
+ u32 switch_freq;
+ u32 num_strings;
+ u32 i_limit;
+ bool cs_out_en;
+ bool ext_gen;
+ bool cabc_en;
+};
+
+struct pm8941_wled {
+ struct regmap *regmap;
+ u16 addr;
+
+ struct led_classdev cdev;
+
+ struct pm8941_wled_config cfg;
+};
+
+static int pm8941_wled_set(struct led_classdev *cdev,
+ enum led_brightness value)
+{
+ struct pm8941_wled *wled;
+ u8 ctrl = 0;
+ u16 val;
+ int rc;
+ int i;
+
+ wled = container_of(cdev, struct pm8941_wled, cdev);
+
+ if (value != 0)
+ ctrl =
Re: [PATCH] ethernet: fm10k: Actually drop 4 bits
On Sat, Jan 24 2015, "Vick, Matthew" wrote: > Good catch! I noticed this too and was getting a patch together to address > this. > > The difference is that I was planning on not silently accepting an invalid > VLAN ID to begin with and returning FM10K_ERR_PARAM if the VLAN was > invalid, which I think is a better approach for this situation. If it's > alright with you, I'll generate the patch shortly and credit you via your > Reported-by. Sure, do what you think is best. Rasmus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: (gtco) use sign_extend32() for sign extension
On Fri, Jan 23, 2015 at 01:29:36PM +0100, Martin Kepplinger wrote: > Signed-off-by: Martin Kepplinger > --- > Despite it's name, sign_extend32() is safe to use for 8 and 16 bit types too. Applied, thank you, but I am sure it can be cleaned up even more. > > > drivers/input/tablet/gtco.c | 11 +++ > 1 file changed, 3 insertions(+), 8 deletions(-) > > diff --git a/drivers/input/tablet/gtco.c b/drivers/input/tablet/gtco.c > index 8580456..272a838 100644 > --- a/drivers/input/tablet/gtco.c > +++ b/drivers/input/tablet/gtco.c > @@ -59,7 +59,7 @@ Scott Hill sh...@gtcocalcomp.com > #include > #include > #include > - > +#include > > #include > > @@ -666,13 +666,8 @@ static void gtco_urb_callback(struct urb *urbinfo) > case 4: > /* Tilt */ > > - /* Sign extend these 7 bit numbers. */ > - if (device->buffer[6] & 0x40) > - device->buffer[6] |= 0x80; > - > - if (device->buffer[7] & 0x40) > - device->buffer[7] |= 0x80; > - > + device->buffer[6] = sign_extend32(device->buffer[6], 6); > + device->buffer[7] = sign_extend32(device->buffer[7], 6); > > valsigned = (device->buffer[6]); > input_report_abs(inputdev, ABS_TILT_X, (s32)valsigned); > -- > 2.1.4 > -- 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] lib: find_*_bit reimplementation
On Mon, Jan 19 2015, Yury Norov wrote:
> New implementation takes less space, and, I hope, easier to understand.
>
> Signed-off-by: Yury Norov
> ---
> lib/find_next_bit.c | 265
> +++-
> 1 file changed, 73 insertions(+), 192 deletions(-)
>
That diffstat is certainly nice. Do you also have numbers for the
size of the generated code, and do you know if there is a
measurable performance difference? Have you tested whether the new and
old code give the same results, also in corner cases?
Some remarks inline below.
> diff --git a/lib/find_next_bit.c b/lib/find_next_bit.c
> index 0cbfc0b..a5c915f 100644
> --- a/lib/find_next_bit.c
> +++ b/lib/find_next_bit.c
> @@ -11,10 +11,39 @@
>
> #include
> #include
> +#include
> #include
> #include
>
> -#define BITOP_WORD(nr) ((nr) / BITS_PER_LONG)
> +#define HIGH_BITS_MASK(nr) (ULONG_MAX << (nr))
> +#define MIN(a, b)((a) < (b) ? (a) : (b))
> +
Please don't duplicate min/max macros. kernel.h already provides everything you
need.
> +#if !defined(find_next_bit) || !defined(find_next_zero_bit)
> +static unsigned long _find_next_bit(const unsigned long *addr,
> + unsigned long end, unsigned long start, unsigned long flags)
Having two parameters called end and start appearing in that
order is slightly confusing. Why not keep the name 'size' for
end, or maybe 'nbits' to make the unit clear. Also, I think flags
should just be a bool and maybe renamed to something more meaningful.
> +{
> + unsigned long tmp = flags ? addr[start / BITS_PER_LONG]
> + : ~addr[start / BITS_PER_LONG];
> +
> + /* Handle 1st word. */
> + if (!IS_ALIGNED(start, BITS_PER_LONG)) {
> + tmp &= HIGH_BITS_MASK(start % BITS_PER_LONG);
> + start = round_down(start, BITS_PER_LONG);
> + }
> +
> + do {
> + if (tmp)
> + return MIN(start + __ffs(tmp), end);
> +
> + start += BITS_PER_LONG;
> + if (start >= end)
> + return end;
> +
> + tmp = flags ? addr[start / BITS_PER_LONG]
> + : ~addr[start / BITS_PER_LONG];
> + } while (1);
> +}
> +#endif
>
> #ifndef find_next_bit
> /*
> @@ -23,86 +52,16 @@
> unsigned long find_next_bit(const unsigned long *addr, unsigned long size,
> unsigned long offset)
> {
> - const unsigned long *p = addr + BITOP_WORD(offset);
> - unsigned long result = offset & ~(BITS_PER_LONG-1);
> - unsigned long tmp;
> -
> - if (offset >= size)
> - return size;
The previous versions handled this, but your code will always access
the word at addr[start/BITS_PER_LONG]. Are you sure no caller ever
passes start >= size?
> - size -= result;
> - offset %= BITS_PER_LONG;
> - if (offset) {
> - tmp = *(p++);
> - tmp &= (~0UL << offset);
> - if (size < BITS_PER_LONG)
> - goto found_first;
> - if (tmp)
> - goto found_middle;
> - size -= BITS_PER_LONG;
> - result += BITS_PER_LONG;
> - }
> - while (size & ~(BITS_PER_LONG-1)) {
> - if ((tmp = *(p++)))
> - goto found_middle;
> - result += BITS_PER_LONG;
> - size -= BITS_PER_LONG;
> - }
> - if (!size)
> - return result;
> - tmp = *p;
> -
> -found_first:
> - tmp &= (~0UL >> (BITS_PER_LONG - size));
> - if (tmp == 0UL) /* Are any bits set? */
> - return result + size; /* Nope. */
> -found_middle:
> - return result + __ffs(tmp);
> + return _find_next_bit(addr, size, offset, 1);
> }
> EXPORT_SYMBOL(find_next_bit);
> #endif
>
> #ifndef find_next_zero_bit
> -/*
> - * This implementation of find_{first,next}_zero_bit was stolen from
> - * Linus' asm-alpha/bitops.h.
> - */
> unsigned long find_next_zero_bit(const unsigned long *addr, unsigned long
> size,
>unsigned long offset)
> {
> - const unsigned long *p = addr + BITOP_WORD(offset);
> - unsigned long result = offset & ~(BITS_PER_LONG-1);
> - unsigned long tmp;
> -
> - if (offset >= size)
> - return size;
> - size -= result;
> - offset %= BITS_PER_LONG;
> - if (offset) {
> - tmp = *(p++);
> - tmp |= ~0UL >> (BITS_PER_LONG - offset);
> - if (size < BITS_PER_LONG)
> - goto found_first;
> - if (~tmp)
> - goto found_middle;
> - size -= BITS_PER_LONG;
> - result += BITS_PER_LONG;
> - }
> - while (size & ~(BITS_PER_LONG-1)) {
> - if (~(tmp = *(p++)))
> - goto found_middle;
> - result += BITS_PER_LONG;
> - size -= BITS_PER_LONG;
> - }
> - if (!size)
> -
Re: [PATCH v2 2/2] genirq: Allow irq_desc to carry the union of stacked irq_chip flags
On 2015/1/23 23:55, Thomas Gleixner wrote:
> On Wed, 14 Jan 2015, Marc Zyngier wrote:
>
>> The current infrastructure for stacked domains doesn't propagate
>> irq_chip flags, and as we only look at the top-level irq_chip,
>> we may miss a number of critical flags.
>>
>> This patch accumulates the flags into a new set, stored at the
>> irq_desc level, with an additional flag to indicate that this is
>> a stack of irqchip. The accessor is updated to return the right one.
>
>> static inline unsigned long irq_desc_get_chip_flags(struct irq_desc *desc)
>> {
>> +#ifdef CONFIG_IRQ_DOMAIN_HIERARCHY
>> +if (desc->chip_flags & IRQCHIP_STACKED_CHIPS)
>> +return desc->chip_flags;
>> +#endif
>> return desc->irq_data.chip->flags;
>
> We can avoid the extra conditional if we just make the accumulated
> flags unconditional and collect them even for the !hierarchy case.
>
> Also this patch is missing that chips can be swapped at runtime either
> via the normal interfaces or via __irq_set_chip_handler_name_locked().
>
> This needs to be addressed otherwise we might end up looking at the
> wrong flags.
I'm splitting irq_data into irq_common_data and irq_data, seems
we could host flags by using irq_common_data instead of irq_desc.
>
> Thanks,
>
> tglx
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH ext4] ext4 crypto: ext4_find_dest_de_crypt() can be static
fs/ext4/namei.c:2056:5: sparse: symbol 'ext4_find_dest_de_crypt' was not declared. Should it be static? Signed-off-by: Fengguang Wu --- namei.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/ext4/namei.c b/fs/ext4/namei.c index 0bd6758..7bbf0f9 100644 --- a/fs/ext4/namei.c +++ b/fs/ext4/namei.c @@ -2053,7 +2053,7 @@ journal_error: } #ifdef CONFIG_EXT4_FS_ENCRYPTION -int ext4_find_dest_de_crypt(struct inode *dir, struct inode *inode, +static int ext4_find_dest_de_crypt(struct inode *dir, struct inode *inode, struct buffer_head *bh, void *buf, int buf_size, const char *name, int namelen, -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[ext4:crypto 17/19] fs/ext4/namei.c:2056:5: sparse: symbol 'ext4_find_dest_de_crypt' was not declared. Should it be static?
tree: git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4.git crypto head: dfc8aa97bd527d156f6e7ee3f0286af2229be45d commit: 2842df91db1447a594331116ee48fbf4647b3dd0 [17/19] ext4 crypto: filename encryption modifications reproduce: # apt-get install sparse git checkout 2842df91db1447a594331116ee48fbf4647b3dd0 make ARCH=x86_64 allmodconfig make C=1 CF=-D__CHECK_ENDIAN__ sparse warnings: (new ones prefixed by >>) >> fs/ext4/namei.c:2056:5: sparse: symbol 'ext4_find_dest_de_crypt' was not >> declared. Should it be static? Please review and possibly fold the followup patch. --- 0-DAY kernel test infrastructureOpen Source Technology Center http://lists.01.org/mailman/listinfo/kbuild Intel Corporation -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] mmc: dw_mmc: exynos: remove incorrect __exit_p()
dw_mci_pltfm_remove() is not (nor should it be) marked as __exit,
so we should not be using __exit_p() wrapper with it.
Signed-off-by: Dmitry Torokhov
---
drivers/mmc/host/dw_mmc-exynos.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mmc/host/dw_mmc-exynos.c b/drivers/mmc/host/dw_mmc-exynos.c
index 12a5eaa..fe32948 100644
--- a/drivers/mmc/host/dw_mmc-exynos.c
+++ b/drivers/mmc/host/dw_mmc-exynos.c
@@ -422,7 +422,7 @@ static const struct dev_pm_ops dw_mci_exynos_pmops = {
static struct platform_driver dw_mci_exynos_pltfm_driver = {
.probe = dw_mci_exynos_probe,
- .remove = __exit_p(dw_mci_pltfm_remove),
+ .remove = dw_mci_pltfm_remove,
.driver = {
.name = "dwmmc_exynos",
.of_match_table = dw_mci_exynos_match,
--
2.2.0.rc0.207.ga3a616c
--
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/
[PATCH] mmc: dw_mmc: rockchip: remove incorrect __exit_p()
dw_mci_pltfm_remove() is not (nor should it be) marked as __exit,
so we should not be using __exit_p() wrapper with it.
Signed-off-by: Dmitry Torokhov
---
drivers/mmc/host/dw_mmc-rockchip.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mmc/host/dw_mmc-rockchip.c
b/drivers/mmc/host/dw_mmc-rockchip.c
index 5650ac4..e2a726a 100644
--- a/drivers/mmc/host/dw_mmc-rockchip.c
+++ b/drivers/mmc/host/dw_mmc-rockchip.c
@@ -133,7 +133,7 @@ static SIMPLE_DEV_PM_OPS(dw_mci_rockchip_pmops,
static struct platform_driver dw_mci_rockchip_pltfm_driver = {
.probe = dw_mci_rockchip_probe,
- .remove = __exit_p(dw_mci_pltfm_remove),
+ .remove = dw_mci_pltfm_remove,
.driver = {
.name = "dwmmc_rockchip",
.of_match_table = dw_mci_rockchip_match,
--
2.2.0.rc0.207.ga3a616c
--
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: [RFC 0/3] Slab allocator array operations
On Fri, 23 Jan 2015, Andrew Morton wrote: > On Fri, 23 Jan 2015 15:37:27 -0600 Christoph Lameter wrote: > > > Attached a series of 3 patches to implement functionality to allocate > > arrays of pointers to slab objects. This can be used by the slab > > allocators to offer more optimized allocation and free paths. > > What's the driver for this? The networking people, I think? If so, > some discussion about that would be useful: who is involved, why they > have this need, who are the people we need to bug to get it tested, > whether this implementation is found adequate, etc. Jesper and I gave a talk at LCA about this. LWN has an article on it. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 1/2] input: Add Qualcomm PM8941 power key driver
From: Courtney Cavin
Signed-off-by: Courtney Cavin
Signed-off-by: Bjorn Andersson
---
drivers/input/misc/Kconfig | 12 ++
drivers/input/misc/Makefile| 1 +
drivers/input/misc/pm8941-pwrkey.c | 281 +
3 files changed, 294 insertions(+)
create mode 100644 drivers/input/misc/pm8941-pwrkey.c
diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
index 23297ab..3306592 100644
--- a/drivers/input/misc/Kconfig
+++ b/drivers/input/misc/Kconfig
@@ -105,6 +105,18 @@ config INPUT_PCSPKR
To compile this driver as a module, choose M here: the
module will be called pcspkr.
+config INPUT_PM8941_PWRKEY
+ tristate "Qualcomm PM8941 power key support"
+ depends on MFD_SPMI_PMIC
+ help
+ Say Y here if you want support for the power key usually found
+ on boards using a Qualcomm PM8941 compatible PMIC.
+
+ If unsure, say Y.
+
+ To compile this driver as a module, choose M here: the module
+ will be called pm8941-pwrkey.
+
config INPUT_PM8XXX_VIBRATOR
tristate "Qualcomm PM8XXX vibrator support"
depends on MFD_PM8XXX
diff --git a/drivers/input/misc/Makefile b/drivers/input/misc/Makefile
index 19c7603..c44f6c2 100644
--- a/drivers/input/misc/Makefile
+++ b/drivers/input/misc/Makefile
@@ -48,6 +48,7 @@ obj-$(CONFIG_INPUT_PCAP) += pcap_keys.o
obj-$(CONFIG_INPUT_PCF50633_PMU) += pcf50633-input.o
obj-$(CONFIG_INPUT_PCF8574)+= pcf8574_keypad.o
obj-$(CONFIG_INPUT_PCSPKR) += pcspkr.o
+obj-$(CONFIG_INPUT_PM8941_PWRKEY) += pm8941-pwrkey.o
obj-$(CONFIG_INPUT_PM8XXX_VIBRATOR)+= pm8xxx-vibrator.o
obj-$(CONFIG_INPUT_PMIC8XXX_PWRKEY)+= pmic8xxx-pwrkey.o
obj-$(CONFIG_INPUT_POWERMATE) += powermate.o
diff --git a/drivers/input/misc/pm8941-pwrkey.c
b/drivers/input/misc/pm8941-pwrkey.c
new file mode 100644
index 000..bc7ba8f
--- /dev/null
+++ b/drivers/input/misc/pm8941-pwrkey.c
@@ -0,0 +1,281 @@
+/* Copyright (c) 2010-2011, Code Aurora Forum. All rights reserved.
+ * Copyright (c) 2014, Sony Mobile Communications Inc.
+ *
+ * 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.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define PON_REV2 0x01
+
+#define PON_RT_STS 0x10
+#define PON_KPDPWR_N_SET BIT(0)
+
+#define PON_PS_HOLD_RST_CTL0x5a
+#define PON_PS_HOLD_RST_CTL2 0x5b
+#define PON_PS_HOLD_ENABLEBIT(7)
+#define PON_PS_HOLD_TYPE_MASK 0x0f
+#define PON_PS_HOLD_TYPE_SHUTDOWN 4
+#define PON_PS_HOLD_TYPE_HARD_RESET 7
+
+#define PON_PULL_CTL 0x70
+#define PON_KPDPWR_PULL_UPBIT(1)
+
+#define PON_DBC_CTL0x71
+#define PON_DBC_DELAY_MASK0x7
+
+
+struct pm8941_pwrkey {
+ struct device *dev;
+ int irq;
+ u32 baseaddr;
+ struct regmap *regmap;
+ struct input_dev *input;
+
+ unsigned int revision;
+ struct notifier_block reboot_notifier;
+};
+
+static int pm8941_reboot_notify(struct notifier_block *nb,
+ unsigned long code, void *unused)
+{
+ struct pm8941_pwrkey *pwrkey = container_of(nb, struct pm8941_pwrkey,
+ reboot_notifier);
+ unsigned int enable_reg;
+ unsigned int reset_type;
+ int rc;
+
+ /* PMICs with revision 0 have the enable bit in same register as ctrl */
+ if (pwrkey->revision == 0)
+ enable_reg = PON_PS_HOLD_RST_CTL;
+ else
+ enable_reg = PON_PS_HOLD_RST_CTL2;
+
+ rc = regmap_update_bits(pwrkey->regmap, pwrkey->baseaddr + enable_reg,
+ PON_PS_HOLD_ENABLE, 0);
+ if (rc)
+ dev_err(pwrkey->dev, "unable to clear ps hold reset enable\n");
+
+ /*
+* Updates of PON_PS_HOLD_ENABLE requires 3 sleep cycles between
+* writes.
+*/
+ usleep_range(100, 1000);
+
+ switch (code) {
+ case SYS_HALT:
+ case SYS_POWER_OFF:
+ reset_type = PON_PS_HOLD_TYPE_SHUTDOWN;
+ break;
+ case SYS_RESTART:
+ default:
+ reset_type = PON_PS_HOLD_TYPE_HARD_RESET;
+ break;
+ };
+
+ rc = regmap_update_bits(pwrkey->regmap,
+ pwrkey->baseaddr + PON_PS_HOLD_RST_CTL,
+
mmotm 2015-01-23-16-19 uploaded
The mm-of-the-moment snapshot 2015-01-23-16-19 has been uploaded to http://www.ozlabs.org/~akpm/mmotm/ mmotm-readme.txt says README for mm-of-the-moment: http://www.ozlabs.org/~akpm/mmotm/ This is a snapshot of my -mm patch queue. Uploaded at random hopefully more than once a week. You will need quilt to apply these patches to the latest Linus release (3.x or 3.x-rcY). The series file is in broken-out.tar.gz and is duplicated in http://ozlabs.org/~akpm/mmotm/series The file broken-out.tar.gz contains two datestamp files: .DATE and .DATE--mm-dd-hh-mm-ss. Both contain the string -mm-dd-hh-mm-ss, followed by the base kernel version against which this patch series is to be applied. This tree is partially included in linux-next. To see which patches are included in linux-next, consult the `series' file. Only the patches within the #NEXT_PATCHES_START/#NEXT_PATCHES_END markers are included in linux-next. A git tree which contains the memory management portion of this tree is maintained at git://git.kernel.org/pub/scm/linux/kernel/git/mhocko/mm.git by Michal Hocko. It contains the patches which are between the "#NEXT_PATCHES_START mm" and "#NEXT_PATCHES_END" markers, from the series file, http://www.ozlabs.org/~akpm/mmotm/series. A full copy of the full kernel tree with the linux-next and mmotm patches already applied is available through git within an hour of the mmotm release. Individual mmotm releases are tagged. The master branch always points to the latest release, so it's constantly rebasing. http://git.cmpxchg.org/?p=linux-mmotm.git;a=summary To develop on top of mmotm git: $ git remote add mmotm git://git.kernel.org/pub/scm/linux/kernel/git/mhocko/mm.git $ git remote update mmotm $ git checkout -b topic mmotm/master $ git send-email mmotm/master.. [...] To rebase a branch with older patches to a new mmotm release: $ git remote update mmotm $ git rebase --onto mmotm/master topic The directory http://www.ozlabs.org/~akpm/mmots/ (mm-of-the-second) contains daily snapshots of the -mm tree. It is updated more frequently than mmotm, and is untested. A git copy of this tree is available at http://git.cmpxchg.org/?p=linux-mmots.git;a=summary and use of this tree is similar to http://git.cmpxchg.org/?p=linux-mmotm.git, described above. This mmotm tree contains the following patches against 3.19-rc5: (patches marked "*" will be included in linux-next) origin.patch i-need-old-gcc.patch arch-alpha-kernel-systblss-remove-debug-check.patch * mm-page_alloc-embed-oom-killing-naturally-into-allocation-slowpath.patch * x86-build-replace-perl-script-with-shell-script.patch * memcg-remove-extra-newlines-from-memcg-oom-kill-log.patch * mm-vmscan-fix-highidx-argument-type.patch * printk-add-dummy-routine-for-when-config_printk=n.patch * rtc-s5m-terminate-s5m_rtc_id-array-with-empty-element.patch * mm-dont-offset-memmap-for-flatmem.patch * mm-pagewalk-call-pte_hole-for-vm_pfnmap-during-walk_page_range.patch * jffs2-bugfix-of-summary-length.patch * fanotify-only-destroy-mark-when-both-mask-and-ignored_mask-are-cleared.patch * fanotify-dont-recalculate-a-marks-mask-if-only-the-ignored-mask-changed.patch * fanotify-dont-recalculate-a-marks-mask-if-only-the-ignored-mask-changed-checkpatch-fixes.patch * fanotify-dont-set-fan_ondir-implicitly-on-a-marks-ignored-mask.patch * fanotify-dont-set-fan_ondir-implicitly-on-a-marks-ignored-mask-checkpatch-fixes.patch * input-route-kbd-leds-through-the-generic-leds-layer.patch * build-superh-without-config_expert.patch * fs-ext4-fsyncc-generic_file_fsync-call-based-on-barrier-flag.patch * ocfs2-dlm-add-missing-dlm_lock_put-when-recovery-master-down.patch * ocfs2-remove-unnecessary-else-in-ocfs2_set_acl.patch * ocfs2-fix-uninitialized-variable-access.patch * ocfs2-fix-wrong-comment.patch * ocfs2-fix-snprintf-format-specifier-in-dlmdebugc.patch * ocfs2-xattr-remove-unused-function.patch * ocfs2-quota_local-remove-unused-function.patch * ocfs2-dlm-dlmdomain-remove-unused-function.patch * ocfs2-fix-journal-commit-deadlock-in-ocfs2_convert_inline_data_to_extents.patch * ocfs2-add-a-mount-option-journal_async_commit-on-ocfs2-filesystem.patch * ocfs2-remove-pointless-assignment-from-ocfs2_calc_refcount_meta_credits.patch * ocfs2-o2net-silence-uninitialized-variable-warning.patch * o2dlm-fix-null-pointer-dereference-in-o2dlm_blocking_ast_wrapper.patch * ocfs2-call-ocfs2_journal_access_di-before-ocfs2_journal_dirty-in-ocfs2_write_end_nolock.patch * ocfs2-avoid-access-invalid-address-when-read-o2dlm-debug-messages.patch * block-restore-proc-partitions-to-not-display-non-partitionable-removable-devices.patch * fs-make-generic_block_fiemap-sig-tolerant.patch * fs-make-generic_block_fiemap-sig-tolerant-fix.patch mm.patch * mm-slub-optimize-alloc-free-fastpath-by-removing-preemption-on-off.patch * mm-slub-optimize-alloc-free-fastpath-by-removing-preemption-on-off-v3.patch *
[PATCH v2 2/2] input: pm8941-pwrkey: Add DT binding documentation
From: Courtney Cavin
Signed-off-by: Courtney Cavin
Signed-off-by: Bjorn Andersson
---
.../bindings/input/qcom,pm8941-pwrkey.txt | 43 ++
1 file changed, 43 insertions(+)
create mode 100644
Documentation/devicetree/bindings/input/qcom,pm8941-pwrkey.txt
diff --git a/Documentation/devicetree/bindings/input/qcom,pm8941-pwrkey.txt
b/Documentation/devicetree/bindings/input/qcom,pm8941-pwrkey.txt
new file mode 100644
index 000..07bf55f
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/qcom,pm8941-pwrkey.txt
@@ -0,0 +1,43 @@
+Qualcomm PM8941 PMIC Power Key
+
+PROPERTIES
+
+- compatible:
+ Usage: required
+ Value type:
+ Definition: must be one of:
+ "qcom,pm8941-pwrkey"
+
+- reg:
+ Usage: required
+ Value type:
+ Definition: base address of registers for block
+
+- interrupts:
+ Usage: required
+ Value type:
+ Definition: key change interrupt; The format of the specifier is
+ defined by the binding document describing the node's
+ interrupt parent.
+
+- debounce:
+ Usage: optional
+ Value type:
+ Definition: time in microseconds that key must be pressed or released
+ for state change interrupt to trigger.
+
+- bias-pull-up:
+ Usage: optional
+ Value type:
+ Definition: presence of this property indicates that the KPDPWR_N pin
+ should be configured for pull up.
+
+EXAMPLE
+
+ pwrkey@800 {
+ compatible = "qcom,pm8941-pwrkey";
+ reg = <0x800>;
+ interrupts = <0x0 0x8 0 IRQ_TYPE_EDGE_BOTH>;
+ debounce = <15625>;
+ bias-pull-up;
+ };
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 0/2] Qualcomm PM8941 power key driver
These patches add dt bindings and a device driver for the power key block in the Qualcomm PM8941 pmic. Changes since v1: * Use a reboot_notifier to set power off/reboot mode * Use irq flags from devicetree * Some style fixes Courtney Cavin (2): input: Add Qualcomm PM8941 power key driver input: pm8941-pwrkey: Add DT binding documentation .../bindings/input/qcom,pm8941-pwrkey.txt | 43 drivers/input/misc/Kconfig | 12 + drivers/input/misc/Makefile| 1 + drivers/input/misc/pm8941-pwrkey.c | 281 + 4 files changed, 337 insertions(+) create mode 100644 Documentation/devicetree/bindings/input/qcom,pm8941-pwrkey.txt create mode 100644 drivers/input/misc/pm8941-pwrkey.c -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ethernet: fm10k: Actually drop 4 bits
On 1/22/15, 2:53 PM, "Rasmus Villemoes" wrote: >The comment explains the intention, but vid has type u16. Before the >inner shift, it is promoted to int, which has plenty of space for all >vid's bits, so nothing is dropped. Use a simple mask instead. > >Signed-off-by: Rasmus Villemoes >--- > drivers/net/ethernet/intel/fm10k/fm10k_pf.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > >diff --git a/drivers/net/ethernet/intel/fm10k/fm10k_pf.c >b/drivers/net/ethernet/intel/fm10k/fm10k_pf.c >index 275423d4f777..b1c57d0166a9 100644 >--- a/drivers/net/ethernet/intel/fm10k/fm10k_pf.c >+++ b/drivers/net/ethernet/intel/fm10k/fm10k_pf.c >@@ -335,7 +335,7 @@ static s32 fm10k_update_xc_addr_pf(struct fm10k_hw >*hw, u16 glort, > return FM10K_ERR_PARAM; > > /* drop upper 4 bits of VLAN ID */ >- vid = (vid << 4) >> 4; >+ vid &= 0x0fff; > > /* record fields */ > mac_update.mac_lower = cpu_to_le32(((u32)mac[2] << 24) | Good catch! I noticed this too and was getting a patch together to address this. The difference is that I was planning on not silently accepting an invalid VLAN ID to begin with and returning FM10K_ERR_PARAM if the VLAN was invalid, which I think is a better approach for this situation. If it's alright with you, I'll generate the patch shortly and credit you via your Reported-by. Cheers, Matthew -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] PCI / PM: Avoid resuming PCI devices during system suspend
On Friday, January 23, 2015 02:55:25 PM Bjorn Helgaas wrote: > On Tue, Jan 20, 2015 at 7:17 PM, Rafael J. Wysocki wrote: > > From: Rafael J. Wysocki > > > > Commit f25c0ae2b4c4 (ACPI / PM: Avoid resuming devices in ACPI PM > > domain during system suspend) modified the ACPI PM domain's system > > suspend callbacks to allow devices attached to it to be left in the > > runtime-suspended state during system suspend so as to optimize > > the suspend process. > > > > This was based on the general mechanism introduced by commit > > aae4518b3124 (PM / sleep: Mechanism to avoid resuming runtime-suspended > > devices unnecessarily). > > > > Extend that approach to PCI devices by modifying the PCI bus type's > > ->prepare callback to return 1 for devices that are runtime-suspended > > when it is being executed and that are in a suitable power state and > > need not be resumed going forward. > > > > Signed-off-by: Rafael J. Wysocki > > I don't profess to understand this, and it seems like something you > could merge via your PM tree. So I trust you to do the right thing > with it :) > > Acked-by: Bjorn Helgaas 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: [RFC PATCH] iio: ak8975: Make sure chipset is always initialized
On Sat, 2015-01-24 at 00:38 +0100, Hartmut Knaack wrote:
> Pandruvada, Srinivas schrieb am 19.01.2015 um 17:56:
> > On Mon, 2015-01-19 at 18:49 +0200, Daniel Baluta wrote:
> >> On Mon, Jan 19, 2015 at 6:44 PM, Pandruvada, Srinivas
> >> wrote:
> >>> On Mon, 2015-01-19 at 16:40 +0200, Daniel Baluta wrote:
> Hello,
>
> On Sat, Dec 20, 2014 at 11:29 PM, Pandruvada, Srinivas
> wrote:
> > +Mika
> >
> > On Sat, 2014-12-20 at 13:26 -0800, Srinivas Pandruvada wrote:
> >> On Sat, 2014-12-20 at 00:25 +0200, Daniel Baluta wrote:
> >>> On Sat, Dec 20, 2014 at 12:16 AM, Hartmut Knaack
> >>> wrote:
> Daniel Baluta schrieb am 18.12.2014 um 18:16:
> > When using ACPI, if acpi_match_device fails then chipset enum will
> > be
> > uninitialized and _def_array[chipset] will point to some bad
> > address.
> >
> >> I am missing something. You are enumerated over i2c device, which was
> >> created from ACPI PNP resource. There is a valid handle or and the
> >> device has an ACPI companion at the least. If this failing, I have to
> >> check the code for acpi i2c.
> >> Can you check why this check failed? We may have bug in i2c handling.
>
> You are right about this. Under normal circumstances, if probe is called
> then acpi_match_device will not fail. I even tried to remove the
> device after probe
> but before acpi_match_device, anyhow acpi_match_device was still
> successful :)
>
> This is more a matter of code correctness.
>
> In ak8975_match_acpi_device we have:
>
> » const struct acpi_device_id *id;
>
> » id = acpi_match_device(dev->driver->acpi_match_table, dev);
> » if (!id)
> » » return NULL;
> » *chipset = (int)id->driver_data;
>
> Compiler complains on the fact that chipset might be uninitialized
> if this returns NULL, and we shouldn't ignore this warning even this case
> will never happen.
>
> >>> Will this fix?
> >>> data->chipset = AK8975;
> >>> before
> >>> ak8975_match_acpi_device(>dev, >chipset);
> >>>
>
> This would fix the compiler warning, but doesn't seem the right solution for
> this issue. Quoting the description of acpi_match_device:
> "Return a pointer to the first matching ID on success or %NULL on failure."
> So, even if it is very unlikely to for it to fail - if it does fail, the
> error should be handled as quick as possible. I would favor Daniels solution
> to check for a valid assignment of name.
>
This should never fail as the device is enumerated by this. So it
doesn't matter as long as you silent compiler warning.
> >>
> >> Yes, this is done in the original patch:
> >>
> >> + *chipset = AK_MAX_TYPE;
> > Since data memory is not zero alloced, other member of data are anyway
> > initialized, so adding this also may be better.
>
> If there did not occur an error condition, it will be assigned a value
> before being checked for valid ranges. And if there is an error, probe
> should be aborted, anyway. So initializing *chipset doesn't seem to add
> any benefit IMHO.
>
> >>
> >> .. and fixes the warning.
> >>
> >> Daniel.
> >
> > N�r��y���b�X��ǧv�^�){.n�+{��*"��^n�r���z���h&�� �G���h�(�階�ݢj"���m�z�ޖ���f���h���~�mml==
> >
>
Re: [PATCH] modsign: overwrite keys with zero before deleting them
Am 24.01.2015 um 00:58 schrieb David Howells: > Alexander Holler wrote: > >> This is for the more paranoid people, also it's >> questionable what paranoid nowadays means. > > shred? Seems to do the same like when using dd, just that it does it moultiple times. And according to an article I've read some years ago, overwrriting a blocks on harddisks multiple times doesn't really make sense because doing it just once is enough (the necessity to do it multiple times seems to have been one of these unexplainable myths in the IT) . So I've no idea if it's worth to use shred and have no idea if it's part of any GNU/Linux system (seems likely as it it's part of coreutils), how it's maintained and how long it will be available. But if requested, I will replace that dd with shred or just feel free to do it yourself. Regards, Alexander Holler -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] Staging: comedi: Fix warning line over 80 character
On Fri, Jan 23, 2015 at 11:23:22PM +0530, jitendra kumar khasdev wrote: > This is patch to file ni_labpc_cs.c that fix warning line > over 80 character which is found by checkpatch tool. > > Signed-off-by: Jitendra Kumar Khasdev > --- > drivers/staging/comedi/drivers/ni_labpc_cs.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/drivers/staging/comedi/drivers/ni_labpc_cs.c > b/drivers/staging/comedi/drivers/ni_labpc_cs.c > index 0a8b322..9858ab1 100644 > --- a/drivers/staging/comedi/drivers/ni_labpc_cs.c > +++ b/drivers/staging/comedi/drivers/ni_labpc_cs.c > @@ -1,7 +1,8 @@ > /* > comedi/drivers/ni_labpc_cs.c > Driver for National Instruments daqcard-1200 boards > -Copyright (C) 2001, 2002, 2003 Frank Mori Hess > > +Copyright (C) 2001, 2002, 2003 Frank Mori Hess > + That looks worse now, please make changes that need to be made and make things better looking. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] usb: Retry port status check on resume to work around RH bugs
The EHCI controller on the RK3288 SoC is violating basic parts of the
USB spec and thereby unable to properly resume a suspended port. It does
not start SOF generation within 3ms of finishing resume signaling, so
the attached device will drop off the bus again. This is a particular
problem with runtime PM, where accessing the device will trigger a
resume that immediately makes it unavailabe (and reenumerate with a new
handle).
Thankfully, the persist feature is generally able to work around stuff
like that. Unfortunately, it doesn't quite work in this particular case
because the controller will turn off the CurrentConnectStatus bit for an
instant while the device is reconnecting, which causes the kernel to
conclude that it permanently disappeared. This patch adds a tiny retry
mechanism to the core port resume code which will catch this case and
shouldn't have any notable impact on other controllers.
Signed-off-by: Julius Werner
---
drivers/usb/core/hub.c | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index aeb50bb..d1d0a66 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -2896,10 +2896,12 @@ static int port_is_suspended(struct usb_hub *hub,
unsigned portstatus)
*/
static int check_port_resume_type(struct usb_device *udev,
struct usb_hub *hub, int port1,
- int status, unsigned portchange, unsigned portstatus)
+ int status, u16 portchange, u16 portstatus)
{
struct usb_port *port_dev = hub->ports[port1 - 1];
+ int retries = 3;
+retry:
/* Is a warm reset needed to recover the connection? */
if (status == 0 && udev->reset_resume
&& hub_port_warm_reset_required(hub, port1, portstatus)) {
@@ -2909,8 +2911,15 @@ static int check_port_resume_type(struct usb_device
*udev,
else if (status || port_is_suspended(hub, portstatus) ||
!port_is_power_on(hub, portstatus) ||
!(portstatus & USB_PORT_STAT_CONNECTION)) {
- if (status >= 0)
+ if (status >= 0) {
+ if (retries--) {
+ udelay(200);
+ status = hub_port_status(hub, port1,
+ , );
+ goto retry;
+ }
status = -ENODEV;
+ }
}
/* Can't do a normal resume if the port isn't enabled,
--
2.1.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: [RFC PATCH v3 2/2] arm: kernel: fix pci_mmap_page_range() offset calculation
On Thu, Nov 13, 2014 at 11:19:16AM +, Lorenzo Pieralisi wrote:
> The pci_mmap_page_range() API should be written to expect offset
> values representing PCI memory resource addresses as seen by user
> space, through the pci_resource_to_user() API.
>
> ARM relies on the standard implementation of pci_resource_to_user()
> which actually is an identity map and exports to user space
> PCI memory resources as they are stored in PCI devices resources
> structures, which represent CPU physical addresses (fixed-up using
> BUS to CPU address conversions) not PCI bus addresses.
>
> Therefore, on ARM platforms where the mapping between CPU and BUS
> address is not a 1:1 the current pci_mmap_page_range() implementation is
> erroneous, in that an additional shift is applied to an already fixed-up
> offset passed from userspace.
>
> Hence, this patch removes the mem_offset from the pgoff calculation
> since the offset as passed from user space already represents the CPU
> physical address corresponding to the resource to be mapped, ie no
> additional offset should be applied.
>
> Cc: Arnd Bergmann
> Cc: Russell King
> Signed-off-by: Lorenzo Pieralisi
Acked-by: Bjorn Helgaas
> ---
> arch/arm/kernel/bios32.c | 10 ++
> 1 file changed, 2 insertions(+), 8 deletions(-)
>
> diff --git a/arch/arm/kernel/bios32.c b/arch/arm/kernel/bios32.c
> index 17a26c1..b56fa2d 100644
> --- a/arch/arm/kernel/bios32.c
> +++ b/arch/arm/kernel/bios32.c
> @@ -626,21 +626,15 @@ int pcibios_enable_device(struct pci_dev *dev, int mask)
> int pci_mmap_page_range(struct pci_dev *dev, struct vm_area_struct *vma,
> enum pci_mmap_state mmap_state, int write_combine)
> {
> - struct pci_sys_data *root = dev->sysdata;
> - unsigned long phys;
> -
> - if (mmap_state == pci_mmap_io) {
> + if (mmap_state == pci_mmap_io)
> return -EINVAL;
> - } else {
> - phys = vma->vm_pgoff + (root->mem_offset >> PAGE_SHIFT);
> - }
>
> /*
>* Mark this as IO
>*/
> vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);
>
> - if (remap_pfn_range(vma, vma->vm_start, phys,
> + if (remap_pfn_range(vma, vma->vm_start, vma->vm_pgoff,
>vma->vm_end - vma->vm_start,
>vma->vm_page_prot))
> return -EAGAIN;
> --
> 2.1.2
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH v3 1/2] drivers: pci: fix pci_mmap_fits() implementation for procfs mmap
On Wed, Jan 21, 2015 at 06:44:56PM +, Lorenzo Pieralisi wrote: > Hi Bjorn, > > On Fri, Nov 21, 2014 at 05:51:14PM +, Bjorn Helgaas wrote: > > On Thu, Nov 13, 2014 at 11:19:15AM +, Lorenzo Pieralisi wrote: > > > The introduction of pci_mmap_fits() in commit: > > > > > > b5ff7df3df9efab511244d5a299fce706c71af48 > > > "Check mapped ranges on sysfs resource files" > > > > > > allowed to check for valid range mappings of PCI resources to user space > > > when mapping PCI resources through the sysfs filesystem. > > > > > > The mapping of resources through the sysfs expects the offset passed > > > by the user through the mmap syscall to be 0, and the pgoff is adjusted > > > by the kernel to memory map the resource to the CPU physical address > > > corresponding to the PCI resource in question. > > > > > > The usage of procfs mapping of PCI resources (/proc/bus/pci files) > > > is more controversial in that userspace programs mapping PCI resources > > > are expected to pass in the mmap offset field either a CPU physical > > > address > > > or a PCI bar value, depending on the architecture. > > > > > > By the time pci_mmap_fits() was used to check PCI resource ranges for > > > procfs PCI resources mapping in commit: > > > > > > 9eff02e2042f96fb2aedd02e032eca1c5333d7 > > > "PCI: check mmap range of /proc/bus/pci files too" > > > > > > the procfs interface for mmapping resources to user space broke, since > > > pci_mmap_fits() expected the offset passed from user space in the mmap > > > call to be 0, not the CPU physical address or PCI BAR value of the > > > resource in question. > > > > > > Subsequent attempts at fixing the pci_mmap_fits() implementation failed > > > to fix the issue (or fixed the issue in some architectures but not for > > > all of them, ARM and SPARC procfs interface PCI resources mapping stayed > > > broken throughout) in particular commits: > > > > > > 8c05cd08a7504b855c265263e84af61aabafa329 > > > "PCI: fix offset check for sysfs mmapped files" > > > > > > and > > > > > > 3b519e4ea618b6943a82931630872907f9ac2c2b > > > "PCI: fix size checks for mmap() on /proc/bus/pci files" > > > > > > fixed procfs PCI resources mapping checks in pci_mmap_fits for some > > > architectures, but not for architectures like SPARC that expects > > > the offset value passed from user space through the mmap syscall > > > (when mapping through procfs) to represent the PCI BAR value of the > > > resource to be mapped. > > > > > > The reason behind the breakage is the following. The addresses stored > > > in PCI device resources for memory spaces correspond to CPU physical > > > addresses, which do not necessarily map 1:1 to PCI bus addresses as > > > programmed in PCI devices configuration spaces. > > > > > > This implies that the sanity checks carried out in pci_mmap_fits() to > > > ensure that the user executes an mmap of a "real" pci resource are > > > erroneous when executed through procfs. Some platforms (ie SPARC) > > > expect the offset value to be passed in (procfs mapping) to be the > > > PCI BAR configuration value as read from the PCI device configuration > > > space, not the fixed-up CPU physical address that is present in PCI > > > device resources. > > > > > > The required pgoff (offset in mmap syscall) value passed from userspace > > > is supposed to represent the resource value exported through > > > /proc/bus/pci/devices when the resource is mmapped though procfs (and 0 > > > when the mapping is carried out through sysfs resource files), which > > > corresponds to the PCI resource filtered through the > > > pci_resource_to_user() > > > API. > > > > > > This patch converts the PCI resource to the expected "user visible" > > > value through pci_resource_to_user() before carrying out sanity checks > > > in pci_mmap_fits() so that the check is carried out on the resource > > > values as expected from the userspace mmap API. > > > > > > Cc: Arnd Bergmann > > > Cc: Jesse Barnes > > > Cc: Bjorn Helgaas > > > Cc: Benjamin Herrenschmidt > > > Cc: Russell King > > > Cc: David S. Miller > > > Cc: Michal Simek > > > Cc: Martin Wilck > > > Signed-off-by: Lorenzo Pieralisi > > > > Hi Lorenzo, > > > > I think this patch is the right thing to do. I'm going to try to write > > patches for microblaze, mips, powerpc, and sparc that implement their > > pci_resource_to_user() in terms of pcibios_resource_to_bus() (the patches > > are easy; it's the arguments for correctness that take time). Then I'll > > try to convince myself that those arches are currently broken and will be > > fixed by your patch below. > > > > But I'll be on vacation all next week, so this will take me some time and > > it may not make the next merge window. > > I do not know if you had time to implement the patches above, I would > like to ask Russell to merge patch 2 of this series though, since (1) it > is a fix in the first place given the current proc/sys interface, and > (2) we need it to remove
Re: [PATCH] modsign: overwrite keys with zero before deleting them
Alexander Holler wrote: > This is for the more paranoid people, also it's > questionable what paranoid nowadays means. shred? 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/
[PATCH 1/1] NVMe: Do not take nsid while a passthrough IO command is being issued via a block device file descriptor
When a passthrough IO command is issued with a specific block device file
descriptor. It should be applied at
the namespace which is associated with that block device file descriptor. This
patch makes such passthrough
command ignore nsid in nvme_passthru_cmd structure. Instead it takes the
namespace ID asscoiated with the
block device descriptor.
Signed-off-by: Yan Liu
---
drivers/block/nvme-core.c | 30 ++
1 file changed, 26 insertions(+), 4 deletions(-)
diff --git a/drivers/block/nvme-core.c b/drivers/block/nvme-core.c
index cb529e9..73c3c97 100644
--- a/drivers/block/nvme-core.c
+++ b/drivers/block/nvme-core.c
@@ -1682,6 +1682,27 @@ static int nvme_submit_io(struct nvme_ns *ns, struct
nvme_user_io __user *uio)
return status;
}
+static int nvme_namespace_sel(struct nvme_dev *dev, struct nvme_ns **ns,
+ struct nvme_passthru_cmd __user *ucmd)
+{
+ struct nvme_ns *ns_ptr;
+ struct nvme_passthru_cmd cmd;
+
+ if (list_empty(>namespaces))
+ return -ENOTTY;
+
+ if (copy_from_user(, ucmd, sizeof(cmd)))
+ return -EFAULT;
+
+ list_for_each_entry(ns_ptr, >namespaces, list) {
+ if (ns_ptr->ns_id == cmd.nsid) {
+ *ns = ns_ptr;
+ return 0;
+ }
+ }
+ return -EINVAL;
+}
+
static int nvme_user_cmd(struct nvme_dev *dev, struct nvme_ns *ns,
struct nvme_passthru_cmd __user *ucmd)
{
@@ -1699,7 +1720,7 @@ static int nvme_user_cmd(struct nvme_dev *dev, struct
nvme_ns *ns,
memset(, 0, sizeof(c));
c.common.opcode = cmd.opcode;
c.common.flags = cmd.flags;
- c.common.nsid = cpu_to_le32(cmd.nsid);
+ c.common.nsid = ns ? cpu_to_le32(ns->ns_id) : cpu_to_le32(cmd.nsid);
c.common.cdw2[0] = cpu_to_le32(cmd.cdw2);
c.common.cdw2[1] = cpu_to_le32(cmd.cdw3);
c.common.cdw10[0] = cpu_to_le32(cmd.cdw10);
@@ -2590,14 +2611,15 @@ static long nvme_dev_ioctl(struct file *f, unsigned int
cmd, unsigned long arg)
{
struct nvme_dev *dev = f->private_data;
struct nvme_ns *ns;
+ int ret;
switch (cmd) {
case NVME_IOCTL_ADMIN_CMD:
return nvme_user_cmd(dev, NULL, (void __user *)arg);
case NVME_IOCTL_IO_CMD:
- if (list_empty(>namespaces))
- return -ENOTTY;
- ns = list_first_entry(>namespaces, struct nvme_ns, list);
+ ret = nvme_namespace_sel(dev, , (void __user *)arg);
+ if (ret)
+ return ret;
return nvme_user_cmd(dev, ns, (void __user *)arg);
default:
return -ENOTTY;
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] pci: Fix infinite loop with ROM image of size 0
On Mon, Jan 19, 2015 at 05:53:20PM +0900, Michel Dänzer wrote:
> From: Michel Dänzer
>
> If the image size would ever read as 0, pci_get_rom_size could keep
> processing the same image over and over again.
>
> Reported-by: Federico
> Cc: sta...@vger.kernel.org
> Signed-off-by: Michel Dänzer
Applied with Alex's ack to pci/resource for v3.20, thanks!
> ---
>
> v2:
> * Use unsigned instead of u16 for the local length variable (not sure if
> the multiplication by 512 could overflow otherwise)
> * Integrate length condition into while statement
> * Add stable tag
>
> drivers/pci/rom.c | 7 ---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/pci/rom.c b/drivers/pci/rom.c
> index f955edb..eb0ad53 100644
> --- a/drivers/pci/rom.c
> +++ b/drivers/pci/rom.c
> @@ -71,6 +71,7 @@ size_t pci_get_rom_size(struct pci_dev *pdev, void __iomem
> *rom, size_t size)
> {
> void __iomem *image;
> int last_image;
> + unsigned length;
>
> image = rom;
> do {
> @@ -93,9 +94,9 @@ size_t pci_get_rom_size(struct pci_dev *pdev, void __iomem
> *rom, size_t size)
> if (readb(pds + 3) != 'R')
> break;
> last_image = readb(pds + 21) & 0x80;
> - /* this length is reliable */
> - image += readw(pds + 16) * 512;
> - } while (!last_image);
> + length = readw(pds + 16);
> + image += length * 512;
> + } while (length && !last_image);
>
> /* never return a size larger than the PCI resource window */
> /* there are known ROMs that get the size wrong */
> --
> 2.1.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: N900 v3.19-rc5 arm atags_to_fdt.c is broken
On Fri 2015-01-23 23:36:36, Pali Rohár wrote:
> On Friday 23 January 2015 22:39:55 Pali Rohár wrote:
> > Hello,
> >
> > when I boot zImage with appended DT n900 in qemu
> > fdt_open_into() function called from file
> > arch/arm/boot/compressed/atags_to_fdt.c (in function
> > atags_to_fdt) always returns -FDT_ERR_NOSPACE.
> >
> > It means that all ATAGS (including cmdline arguments) passed
> > by bootloader are ignored.
> >
> > On real n900 device I see that booted DT version also ignore
> > cmdline arguments from bootloader. I cannot debug decompress
> > code on real device, but I think it is same problem as in
> > qemu.
>
> Looks like this quick patch is fixing above problem:
So... something overruns stack, and bigger stack fixes it...?
Pavel
> diff --git a/arch/arm/boot/compressed/head.S b/arch/arm/boot/compressed/head.S
> index 68be901..4a7d75b 100644
> --- a/arch/arm/boot/compressed/head.S
> +++ b/arch/arm/boot/compressed/head.S
> @@ -268,7 +268,7 @@ restart: adr r0, LC0
>* area. No GOT fixup has occurred yet, but none of the
>* code we're about to call uses any global variable.
> */
> - add sp, sp, #0x1
> + add sp, sp, #0x2
> stmfd sp!, {r0-r3, ip, lr}
> mov r0, r8
> mov r1, r6
> @@ -289,7 +289,7 @@ restart: adr r0, LC0
> bleqatags_to_fdt
>
> ldmfd sp!, {r0-r3, ip, lr}
> - sub sp, sp, #0x1
> + sub sp, sp, #0x2
> #endif
>
> mov r8, r6 @ use the appended device tree
>
>
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.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: [RFC PATCH] sched, timer: Use atomics for thread_group_cputimer stats
On Fri, 2015-01-23 at 21:08 +0100, Peter Zijlstra wrote:
> On Fri, Jan 23, 2015 at 11:23:36AM -0800, Jason Low wrote:
> > On Fri, 2015-01-23 at 10:25 +0100, Peter Zijlstra wrote:
> > > On Thu, Jan 22, 2015 at 07:31:53PM -0800, Jason Low wrote:
> > > > +static void update_gt_cputime(struct thread_group_cputimer *a, struct
> > > > task_cputime *b)
> > > > {
> > > > + if (b->utime > atomic64_read(>utime))
> > > > + atomic64_set(>utime, b->utime);
> > > >
> > > > + if (b->stime > atomic64_read(>stime))
> > > > + atomic64_set(>stime, b->stime);
> > > >
> > > > + if (b->sum_exec_runtime > atomic64_read(>sum_exec_runtime))
> > > > + atomic64_set(>sum_exec_runtime, b->sum_exec_runtime);
> > > > }
> > >
> > > See something like this is not safe against concurrent adds.
> >
> > How about something like:
> >
> > u64 a_utime, a_stime, a_sum_exec_runtime;
> >
> > retry_utime:
> > a_utime = atomic64_read(>utime);
> > if (b->utime > a_utime) {
> > if (atomic64_cmpxchg(>utime, a_utime, b->utime) != a_utime)
> > goto retry_utime;
> > }
> >
> > retry_stime:
> > a_stime = atomic64_read(>stime);
> > if (b->stime > a_stime) {
> > if (atomic64_cmpxchg(>stime, a_stime, b->stime) != a_stime)
> > goto retry_stime;
> > }
> >
> > retry_sum_exec_runtime:
> > a_sum_exec_runtime = atomic64_read(>sum_exec_runtime);
> > if (b->sum_exec_runtime > a_sum_exec_runtime) {
> > if (atomic64_cmpxchg(>sum_exec_runtime, a_sum_exec_runtime,
> > b->sum_exec_runtime) != a_sum_exec_runtime)
> > goto retry_sum_exec_runtime;
> > }
>
> Disgusting, at least use an inline or macro to avoid repeating it :-)
Okay, let me see if I can make that a bit more readable :)
On a side note, if we just move the cputimer->running = 1 to after the
call to update_gt_cputime in thread_group_cputimer(), then we don't have
to worry about concurrent adds occuring in this function?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] Add security hooks to binder and implement the hooks for SELinux.
On Fri, Jan 23, 2015 at 01:56:28PM -0800, Casey Schaufler wrote: > On 1/22/2015 6:30 PM, Greg KH wrote: > > On Thu, Jan 22, 2015 at 01:47:29PM -0500, Stephen Smalley wrote: > >> On Thu, Jan 22, 2015 at 1:09 PM, Casey Schaufler > >> wrote: > >>> On 1/22/2015 12:51 AM, Greg KH wrote: > On Wed, Jan 21, 2015 at 10:54:10AM -0500, Stephen Smalley wrote: > > Add security hooks to the binder and implement the hooks for SELinux. > > The security hooks enable security modules such as SELinux to implement > > controls over binder IPC. The security hooks include support for > > controlling what process can become the binder context manager > > (binder_set_context_mgr), controlling the ability of a process > > to invoke a binder transaction/IPC to another process > > (binder_transaction), > > controlling the ability of a process to transfer a binder reference to > > another process (binder_transfer_binder), and controlling the ability > > of a process to transfer an open file to another process > > (binder_transfer_file). > > > > These hooks have been included in the Android kernel trees since > > Android 4.3. > Very interesting, I missed the fact that these were added in that tree, > thanks for digging it out and submitting it. > > I'd like some acks from some Android developers before I take these. > Or, if it's easier for them to go through the security tree, that's fine > with me as well. > >>> My only concern is that we're about to see a set of hooks proposed > >>> for kdbus as well, and it would be a shame if we had two sets of hooks > >>> that do roughly the same thing (ok, *very roughly*) introduced back to > >>> back. > >> Not sure how much commonality there truly is among them (based on the > >> last set of proposed kdbus lsm hooks that I saw, admittedly a while > >> ago) and modules may want to distinguish between the two > >> forms of IPC regardless. The binder hooks have been in place in the > >> Android kernel trees for quite some time, so this patch is just making > >> the mainline binder driver consistent with what is already in Android. > >> If it turns out that there is significant duplication when the kdbus > >> lsm hooks land, I'd be happy to help coalesce them. > > Yeah, I would wait and see what happens with how the kdbus hooks look > > before worrying about this all that much. As people are using the > > binder hooks today, and binder is in the kernel tree, but kdbus isn't, > > let's not worry about kdbus until that is merged. > > That seems like a sane plan to me in light of the situation. I am somewhat > concerned about the growth in special case security behavior. The tun hooks, > now the binder hooks and later the kdbus hooks. It looks like we're going > in the direction of special policies for each kind of communication rather > than a system IPC policy. On the other hand, that appears to be the trend in > system security overall, so even I can see that it may be prudent. If you know of some way to make a more "unified" system IPC policy, that would be great to have, I don't know if anyone is even considering that work, as it seems people are just more concerned about addressing the more real issues of the different IPC methods these days. Maybe it would be a good research project for someone to write a thesis on? :) thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] clk: zynq: Force CPU_2X clock to be ungated
The CPU_2X clock does not have a classical in kernel user, but is, amongst other things, required for OCM and debug access. Make sure this clock does not mistakenly disabled during boot up by enabling it in the platforms clock driver. Signed-off-by: Soren Brinkmann --- I just noticed this on Linus' latest tip. I can't remember having had issues connecting the debugger before, but it might be a candidate for stable in case people report something like that. Sören drivers/clk/zynq/clkc.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/clk/zynq/clkc.c b/drivers/clk/zynq/clkc.c index c363106ed726..f8469315161d 100644 --- a/drivers/clk/zynq/clkc.c +++ b/drivers/clk/zynq/clkc.c @@ -346,6 +346,7 @@ static void __init zynq_clk_setup(struct device_node *np) clks[cpu_2x] = clk_register_gate(NULL, clk_output_name[cpu_2x], "cpu_2x_div", CLK_IGNORE_UNUSED, SLCR_ARM_CLK_CTRL, 26, 0, _lock); + clk_prepare_enable(clks[cpu_2x]); clk = clk_register_fixed_factor(NULL, "cpu_1x_div", "cpu_div", 0, 1, 4 + 2 * tmp); -- 2.2.2.1.g63c5777 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 4/6] of/pci: add of_pci_dma_configure() update dma configuration
On Fri, Jan 23, 2015 at 05:32:37PM -0500, Murali Karicheri wrote:
> Add of_pci_dma_configure() to allow updating the dma configuration
> of the pci device using the configuration from DT of the parent of
> the root bridge device.
>
> Cc: Joerg Roedel
> Cc: Grant Likely
> Cc: Rob Herring
> Cc: Bjorn Helgaas
> Cc: Will Deacon
> Cc: Russell King
> Cc: Arnd Bergmann
> Cc: Suravee Suthikulpanit
>
> Signed-off-by: Murali Karicheri
> ---
> drivers/of/of_pci.c| 39 +++
> include/linux/of_pci.h | 12
> 2 files changed, 51 insertions(+)
>
> diff --git a/drivers/of/of_pci.c b/drivers/of/of_pci.c
> index 88471d3..34878c9 100644
> --- a/drivers/of/of_pci.c
> +++ b/drivers/of/of_pci.c
> @@ -2,6 +2,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
>
> @@ -229,6 +230,44 @@ parse_failed:
> return err;
> }
> EXPORT_SYMBOL_GPL(of_pci_get_host_bridge_resources);
> +
> +/**
> + * of_get_pci_root_bridge_parent - get the OF node of the root bridge's
> parent
> + * @dev: ptr to pci_dev struct of the pci device
> + *
> + * This function will traverse the bus up to the root bus starting with
> + * the child and return the OF node ptr to root bridge device's parent
> device.
> + */
> +struct device_node *of_get_pci_root_bridge_parent(struct pci_dev *dev)
I'm not an OF person, but this interface seems like it might be too
special-purpose. Maybe it would be enough to add
"of_get_pci_root_bridge()", and the caller could do this:
struct device *bridge = of_get_pci_root_bridge(dev);
struct device_node *parent_np = bridge->parent->of_node;
Also, the name "of_get_..." suggests that it increments a refcount, as
of_get_parent() does. But you aren't doing anything with the refcount.
But I guess an "of_get_pci_root_bridge()" isn't doing anything OF-related,
so maybe we should just add a "pci_get_host_bridge(struct pci_dev *)"
to PCI instead.
Bjorn
> +{
> + struct pci_bus *bus = dev->bus;
> + struct device *bridge;
> +
> + while (!pci_is_root_bus(bus))
> + bus = bus->parent;
> + bridge = bus->bridge;
> +
> + return bridge->parent->of_node;
> +}
> +EXPORT_SYMBOL_GPL(of_get_pci_root_bridge_parent);
> +
> +/**
> + * of_pci_dma_configure - Setup DMA configuration
> + * @dev: ptr to pci_dev struct of the pci device
> + *
> + * Function to update PCI devices's DMA configuration using the same
> + * info from the OF node of root host bridge's parent.
> + */
> +void of_pci_dma_configure(struct pci_dev *pci_dev)
> +{
> + struct device *dev = _dev->dev;
> + struct device_node *parent_np;
> +
> + parent_np = of_get_pci_root_bridge_parent(pci_dev);
> + of_dma_configure(dev, parent_np);
> +}
> +EXPORT_SYMBOL_GPL(of_pci_dma_configure);
> +
> #endif /* CONFIG_OF_ADDRESS */
>
> #ifdef CONFIG_PCI_MSI
> diff --git a/include/linux/of_pci.h b/include/linux/of_pci.h
> index ce0e5ab..0465a2a 100644
> --- a/include/linux/of_pci.h
> +++ b/include/linux/of_pci.h
> @@ -16,6 +16,8 @@ int of_pci_get_devfn(struct device_node *np);
> int of_irq_parse_and_map_pci(const struct pci_dev *dev, u8 slot, u8 pin);
> int of_pci_parse_bus_range(struct device_node *node, struct resource *res);
> int of_get_pci_domain_nr(struct device_node *node);
> +struct device_node *of_get_pci_root_bridge_parent(struct pci_dev *dev);
> +void of_pci_dma_configure(struct pci_dev *pci_dev);
> #else
> static inline int of_irq_parse_pci(const struct pci_dev *pdev, struct
> of_phandle_args *out_irq)
> {
> @@ -50,6 +52,16 @@ of_get_pci_domain_nr(struct device_node *node)
> {
> return -1;
> }
> +
> +static inline struct device_node
> +*of_get_pci_root_bridge_parent(struct pci_dev *dev)
> +{
> + return NULL;
> +}
> +
> +static inline void of_pci_dma_configure(struct pci_dev *pci_dev)
> +{
> +}
> #endif
>
> #if defined(CONFIG_OF_ADDRESS)
> --
> 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: [RFC PATCH] sched, timer: Use atomics for thread_group_cputimer stats
On Fri, 2015-01-23 at 21:08 +0100, Peter Zijlstra wrote:
> On Fri, Jan 23, 2015 at 11:23:36AM -0800, Jason Low wrote:
> > On Fri, 2015-01-23 at 10:25 +0100, Peter Zijlstra wrote:
> > > On Thu, Jan 22, 2015 at 07:31:53PM -0800, Jason Low wrote:
> > > > +static void update_gt_cputime(struct thread_group_cputimer *a, struct
> > > > task_cputime *b)
> > > > {
> > > > + if (b->utime > atomic64_read(>utime))
> > > > + atomic64_set(>utime, b->utime);
> > > >
> > > > + if (b->stime > atomic64_read(>stime))
> > > > + atomic64_set(>stime, b->stime);
> > > >
> > > > + if (b->sum_exec_runtime > atomic64_read(>sum_exec_runtime))
> > > > + atomic64_set(>sum_exec_runtime, b->sum_exec_runtime);
> > > > }
> > >
> > > See something like this is not safe against concurrent adds.
> >
> > How about something like:
> >
> > u64 a_utime, a_stime, a_sum_exec_runtime;
> >
> > retry_utime:
> > a_utime = atomic64_read(>utime);
> > if (b->utime > a_utime) {
> > if (atomic64_cmpxchg(>utime, a_utime, b->utime) != a_utime)
> > goto retry_utime;
> > }
> >
> > retry_stime:
> > a_stime = atomic64_read(>stime);
> > if (b->stime > a_stime) {
> > if (atomic64_cmpxchg(>stime, a_stime, b->stime) != a_stime)
> > goto retry_stime;
> > }
> >
> > retry_sum_exec_runtime:
> > a_sum_exec_runtime = atomic64_read(>sum_exec_runtime);
> > if (b->sum_exec_runtime > a_sum_exec_runtime) {
> > if (atomic64_cmpxchg(>sum_exec_runtime, a_sum_exec_runtime,
> > b->sum_exec_runtime) != a_sum_exec_runtime)
> > goto retry_sum_exec_runtime;
> > }
>
> Disgusting, at least use an inline or macro to avoid repeating it :-)
>
> Also, does anyone care about performance on 32bit systems? There's a few
> where atomic64 is abysmal.
Yeah, though we're also avoiding spin lock/unlock calls each time, so
not sure if we're really adding anything of significance to the "overall
cost" on 32 bit systems. And update_gt_cputime wouldn't get called too
frequently.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] iio: ak8975: Make sure chipset is always initialized
Pandruvada, Srinivas schrieb am 19.01.2015 um 17:56:
> On Mon, 2015-01-19 at 18:49 +0200, Daniel Baluta wrote:
>> On Mon, Jan 19, 2015 at 6:44 PM, Pandruvada, Srinivas
>> wrote:
>>> On Mon, 2015-01-19 at 16:40 +0200, Daniel Baluta wrote:
Hello,
On Sat, Dec 20, 2014 at 11:29 PM, Pandruvada, Srinivas
wrote:
> +Mika
>
> On Sat, 2014-12-20 at 13:26 -0800, Srinivas Pandruvada wrote:
>> On Sat, 2014-12-20 at 00:25 +0200, Daniel Baluta wrote:
>>> On Sat, Dec 20, 2014 at 12:16 AM, Hartmut Knaack
>>> wrote:
Daniel Baluta schrieb am 18.12.2014 um 18:16:
> When using ACPI, if acpi_match_device fails then chipset enum will be
> uninitialized and _def_array[chipset] will point to some bad
> address.
>
>> I am missing something. You are enumerated over i2c device, which was
>> created from ACPI PNP resource. There is a valid handle or and the
>> device has an ACPI companion at the least. If this failing, I have to
>> check the code for acpi i2c.
>> Can you check why this check failed? We may have bug in i2c handling.
You are right about this. Under normal circumstances, if probe is called
then acpi_match_device will not fail. I even tried to remove the
device after probe
but before acpi_match_device, anyhow acpi_match_device was still
successful :)
This is more a matter of code correctness.
In ak8975_match_acpi_device we have:
» const struct acpi_device_id *id;
» id = acpi_match_device(dev->driver->acpi_match_table, dev);
» if (!id)
» » return NULL;
» *chipset = (int)id->driver_data;
Compiler complains on the fact that chipset might be uninitialized
if this returns NULL, and we shouldn't ignore this warning even this case
will never happen.
>>> Will this fix?
>>> data->chipset = AK8975;
>>> before
>>> ak8975_match_acpi_device(>dev, >chipset);
>>>
This would fix the compiler warning, but doesn't seem the right solution for
this issue. Quoting the description of acpi_match_device:
"Return a pointer to the first matching ID on success or %NULL on failure."
So, even if it is very unlikely to for it to fail - if it does fail, the
error should be handled as quick as possible. I would favor Daniels solution
to check for a valid assignment of name.
>>
>> Yes, this is done in the original patch:
>>
>> + *chipset = AK_MAX_TYPE;
> Since data memory is not zero alloced, other member of data are anyway
> initialized, so adding this also may be better.
If there did not occur an error condition, it will be assigned a value
before being checked for valid ranges. And if there is an error, probe
should be aborted, anyway. So initializing *chipset doesn't seem to add
any benefit IMHO.
>>
>> .. and fixes the warning.
>>
>> Daniel.
>
> N�r��y���b�X��ǧv�^�){.n�+{��*"��^n�r���z���h&�� �G���h�(�階�ݢj"���m�z�ޖ���f���h���~�mml==
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] net: dsa/mv88e6352: make mv88e6352_wait generic
Some busy bits are available in the global register 1, such as the ATU
Busy bit. We may want to use this function to wait for them to change,
so add a new parameter to mv88e6352_wait() instead of hard-coding
REG_GLOBAL2.
In the meantime, since the REG_READ() macro already checks for error,
remove the redundant check for ret < 0.
Signed-off-by: Vivien Didelot
---
drivers/net/dsa/mv88e6352.c | 13 +
1 file changed, 5 insertions(+), 8 deletions(-)
diff --git a/drivers/net/dsa/mv88e6352.c b/drivers/net/dsa/mv88e6352.c
index 258d9ef..e13adc7 100644
--- a/drivers/net/dsa/mv88e6352.c
+++ b/drivers/net/dsa/mv88e6352.c
@@ -22,17 +22,14 @@
#include
#include "mv88e6xxx.h"
-static int mv88e6352_wait(struct dsa_switch *ds, int reg, u16 mask)
+static int mv88e6352_wait(struct dsa_switch *ds, int reg, int offset, u16 mask)
{
unsigned long timeout = jiffies + HZ / 10;
while (time_before(jiffies, timeout)) {
int ret;
- ret = REG_READ(REG_GLOBAL2, reg);
- if (ret < 0)
- return ret;
-
+ ret = REG_READ(reg, offset);
if (!(ret & mask))
return 0;
@@ -43,17 +40,17 @@ static int mv88e6352_wait(struct dsa_switch *ds, int reg,
u16 mask)
static inline int mv88e6352_phy_wait(struct dsa_switch *ds)
{
- return mv88e6352_wait(ds, 0x18, 0x8000);
+ return mv88e6352_wait(ds, REG_GLOBAL2, 0x18, 0x8000);
}
static inline int mv88e6352_eeprom_load_wait(struct dsa_switch *ds)
{
- return mv88e6352_wait(ds, 0x14, 0x0800);
+ return mv88e6352_wait(ds, REG_GLOBAL2, 0x14, 0x0800);
}
static inline int mv88e6352_eeprom_busy_wait(struct dsa_switch *ds)
{
- return mv88e6352_wait(ds, 0x14, 0x8000);
+ return mv88e6352_wait(ds, REG_GLOBAL2, 0x14, 0x8000);
}
static int __mv88e6352_phy_read(struct dsa_switch *ds, int addr, int regnum)
--
2.2.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: [GIT PULL] at91: cleanup/soc for 3.20 #3
On 23/01/2015 at 18:15:07 +0100, Nicolas Ferre wrote : > Arnd, Olof, Kevin, > > This is a batch of cleanup/soc modifications that you may also stack on top of > your "soc" branch as the previous one. It stabilizes a little bit our cleanup > action before going further. > I also have the feeling that multi-platform would be hard to reach for 3.20... > If I'm not mistaken, rc6 is on sunday, so anything else is probably too late. -- Alexandre Belloni, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 5/6] PCI: update dma configuration from DT
On Fri, Jan 23, 2015 at 05:32:38PM -0500, Murali Karicheri wrote: > If there is a DT node available for the root bridge's parent device, > use the dma configuration from that device node. For example, keystone > PCI devices would require dma_pfn_offset to be set correctly in the > device structure of the pci device in order to have the correct dma mask. > The DT node will have dma-ranges defined for this. Also support using > the DT property dma-coherent to allow coherent DMA operation by the > PCI device. > > This patch use the new helper function of_pci_dma_configure() to update > the device dma configuration. > > Cc: Joerg Roedel > Cc: Grant Likely > Cc: Rob Herring > Cc: Bjorn Helgaas > Cc: Will Deacon > Cc: Russell King > Cc: Arnd Bergmann > Cc: Suravee Suthikulpanit > > Signed-off-by: Murali Karicheri I assume this series will be merged via some non-PCI tree, so: Acked-by: Bjorn Helgaas > --- > drivers/pci/probe.c |2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c > index 23212f8..d7dcd6c 100644 > --- a/drivers/pci/probe.c > +++ b/drivers/pci/probe.c > @@ -6,6 +6,7 @@ > #include > #include > #include > +#include > #include > #include > #include > @@ -1520,6 +1521,7 @@ void pci_device_add(struct pci_dev *dev, struct pci_bus > *bus) > dev->dev.dma_mask = >dma_mask; > dev->dev.dma_parms = >dma_parms; > dev->dev.coherent_dma_mask = 0xull; > + of_pci_dma_configure(dev); > > pci_set_dma_max_seg_size(dev, 65536); > pci_set_dma_seg_boundary(dev, 0x); > -- > 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] PCI: xgene: Include clk.h instead of clk-private.h
On Thu, Jan 22, 2015 at 11:25:54AM -0800, Stephen Boyd wrote: > This driver should be including clk.h as it's a clock consumer, > not a clock provider that needs to register clocks early. > > Cc: Tanmay Inamdar > Signed-off-by: Stephen Boyd Applied provisionally to pci/host-xgene for v3.20, thanks! I'm hoping for an ack from Tanmay. > --- > drivers/pci/host/pci-xgene.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/pci/host/pci-xgene.c b/drivers/pci/host/pci-xgene.c > index b1d0596457c5..fdb348d3ccd3 100644 > --- a/drivers/pci/host/pci-xgene.c > +++ b/drivers/pci/host/pci-xgene.c > @@ -16,7 +16,7 @@ > * GNU General Public License for more details. > * > */ > -#include > +#include > #include > #include > #include > -- > The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, > a Linux Foundation Collaborative Project > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] PCI: Add Wellsburg (X99) to Intel PCH root port ACS quirk
On Thu, Jan 22, 2015 at 11:15:43AM -0700, Alex Williamson wrote:
> Intel has confirmed that the Wellsburg chipset, while not reporting
> ACS, does provide the proper isolation through the RCBA/BSPR
> registers, so the same quirk works for this set of device IDs.
>
> Signed-off-by: Alex Williamson
> Cc: Don Dugger
Applied with Don's ack to pci/virtualization for v3.20, thanks!
> ---
>
> drivers/pci/quirks.c |3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
> index ed6f89b..2cdb789 100644
> --- a/drivers/pci/quirks.c
> +++ b/drivers/pci/quirks.c
> @@ -3630,6 +3630,9 @@ static const u16 pci_quirk_intel_pch_acs_ids[] = {
> 0x9c98, 0x9c99, 0x9c9a, 0x9c9b,
> /* Patsburg (X79) PCH */
> 0x1d10, 0x1d12, 0x1d14, 0x1d16, 0x1d18, 0x1d1a, 0x1d1c, 0x1d1e,
> + /* Wellsburg (X99) PCH */
> + 0x8d10, 0x8d11, 0x8d12, 0x8d13, 0x8d14, 0x8d15, 0x8d16, 0x8d17,
> + 0x8d18, 0x8d19, 0x8d1a, 0x8d1b, 0x8d1c, 0x8d1d, 0x8d1e,
> };
>
> static bool pci_quirk_intel_pch_acs_match(struct pci_dev *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 08/12] pm: at91: rename file name: pm_slowclock.S -->pm_suspend.S
Hi, On 23/01/2015 at 20:17:19 +0100, Sylvain Rochet wrote : > Hello Wenyou, > > On Tue, Jan 20, 2015 at 04:17:01PM +0800, Wenyou Yang wrote: > > > > diff --git a/arch/arm/mach-at91/pm_suspend.S > > b/arch/arm/mach-at91/pm_suspend.S > > new file mode 100644 > > index 000..420e730 > > --- /dev/null > > > > + /* Turn off the main oscillator */ > > + ldr tmp1, [pmc, #AT91_CKGR_MOR] > > + bic tmp1, tmp1, #AT91_PMC_MOSCEN > > at91sam9x5 and probably others need a key here: > orr tmp1, tmp1, #AT91_PMC_KEY > > > + str tmp1, [pmc, #AT91_CKGR_MOR] > > > > > + /* Wait for interrupt */ > > + mcr p15, 0, tmp1, c7, c0, 4 > > The linux-3.10-at91 branch uses a different approach which seem > necessary for newer board, you probably forget to merge the following: > > /* > * Put the processor to enter into Standby mode, wait for interrupt to wakeup > */ > .macro _do_wfi > > #if defined(CONFIG_CPU_V7) > dsb > > /* Disable the processor clock */ > mov tmp1, #AT91_PMC_PCK > str tmp1, [pmc, #AT91_PMC_SCDR] > > wfi @ Wait For Interrupt > #else > mcr p15, 0, tmp1, c7, c0, 4 > #endif > > .endm > > .text > > ENTRY(at91_slow_clock) > (...) > /* Wait for interrupt */ > _do_wfi > (...) > > > > > > + /* Turn on the main oscillator */ > > + ldr tmp1, [pmc, #AT91_CKGR_MOR] > > + orr tmp1, tmp1, #AT91_PMC_MOSCEN > > at91sam9x5 and probably others need a key here: > orr tmp1, tmp1, #AT91_PMC_KEY > > > + str tmp1, [pmc, #AT91_CKGR_MOR] > > > > What about the following parts which are also in linux-3.10-at91 branch > but not in this rework, are they necessary ? > > sdr_sr_done: > /* Disable MPDDRC Clock*/ > cmp ddrcid, #0 > beq 2f > bic tmp2, ddrcid, #0xe0 /* fetch lowest 5 bits */ > mov tmp1, #0x01 > mov tmp1, tmp1, lsl tmp2 > > tst ddrcid, #0x20 /* > 32 ? */ > beq 1f > str tmp1, [pmc, #AT91_PMC_PCDR1] > b 2f > 1: > str tmp1, [pmc, #AT91_PMC_PCDR] > 2: > > /* Disable DDR Clock */ > mov tmp1, #AT91_PMC_SYS_DDR > str tmp1, [pmc, #AT91_PMC_SCDR] > > > > > /* Enable MPDDRC Clock*/ > cmp ddrcid, #0 > beq 4f > bic tmp2, ddrcid, #0xe0 /* fetch lowest 5 bits */ > mov tmp1, #0x01 > mov tmp1, tmp1, lsl tmp2 > > tst ddrcid, #0x20 /* > 32 ? */ > beq 3f > str tmp1, [pmc, #AT91_PMC_PCER1] > b 4f > 3: > str tmp1, [pmc, #AT91_PMC_PCER] > 4: > > /* Enable DDR clock */ > mov tmp1, #AT91_PMC_SYS_DDR > str tmp1, [pmc, #AT91_PMC_SCER] > > This is a rework, what is part of linux-3.10-at91 and not yet present in mainline should be part of a following series. I would prefer not mixing reworks and "new" functionalities (they have been present in the atmel tree for a while but never mainlined). I would say that PM on 9x5, n12 and sama5 in mainline is clearly not well tested and is lagging behind the atmel tree. -- Alexandre Belloni, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: rcu, sched: WARNING: CPU: 30 PID: 23771 at kernel/rcu/tree_plugin.h:337 rcu_read_unlock_special+0x369/0x550()
On Fri, Jan 23, 2015 at 06:05:25PM -0500, Sasha Levin wrote:
> On 01/23/2015 05:54 PM, Paul E. McKenney wrote:
> > On Fri, Jan 23, 2015 at 04:51:52PM -0500, Sasha Levin wrote:
> >> > On 01/23/2015 04:36 AM, Paul E. McKenney wrote:
> >>> > > diff --git a/kernel/rcu/tree_plugin.h b/kernel/rcu/tree_plugin.h
> >>> > > index 8669de884445..ec99dc16aa38 100644
> >>> > > --- a/kernel/rcu/tree_plugin.h
> >>> > > +++ b/kernel/rcu/tree_plugin.h
> >>> > > @@ -322,6 +322,7 @@ void rcu_read_unlock_special(struct task_struct
> >>> > > *t)
> >>> > > special = t->rcu_read_unlock_special;
> >>> > > if (special.b.need_qs) {
> >>> > > rcu_preempt_qs();
> >>> > > + t->rcu_read_unlock_special.need_qs = false;
> >> >
> >> > It didn't compile, I've used:
> >> >
> >> > t->rcu_read_unlock_special.b.need_qs = false;
> > Apologies, I should have marked it "untested". Good show on finding
> > the correct fix.
> >
> > But does your fixed version help? ;-)
>
> I haven't seen it happening it again, but you won't get a "yes" out of me
> until tomorrow evening :)
Fair enough! ;-)
Thanx, Paul
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 07/12] pm: at91: the standby mode uses the same sram function as the suspend to memory mode
On 23/01/2015 at 17:50:20 +0100, Sylvain Rochet wrote :
> Hello Wenyou,
>
>
> On Tue, Jan 20, 2015 at 04:17:00PM +0800, Wenyou Yang wrote:
> >
> > diff --git a/arch/arm/mach-at91/pm.c b/arch/arm/mach-at91/pm.c
> > index 691e6db..a1010f0 100644
> > --- a/arch/arm/mach-at91/pm.c
> > +++ b/arch/arm/mach-at91/pm.c
>
>
> > @@ -145,62 +145,51 @@ extern void at91_slow_clock(void __iomem *pmc, void
> > __iomem *ramc0,
> > void __iomem *ramc1, int memctrl);
> > extern u32 at91_slow_clock_sz;
> >
> > +static void at91_pm_suspend(suspend_state_t state)
> > +{
> (...)
> > + slow_clock(at91_pmc_base, at91_ramc_base[0],
> > + at91_ramc_base[1], pm_data);
> > +}
>
>
> > - if (slow_clock) {
> > - slow_clock(at91_pmc_base, at91_ramc_base[0],
> > - at91_ramc_base[1],
> > - at91_pm_data.memctrl);
> (...)
> > + at91_pm_suspend(state);
>
>
> By doing that you removed the condition "if (slow_clock)".
>
> But slow_clock can still be NULL, see commit d2e4679, there are multiple
> reasons which ends up with a NULL slow_clock.
>
I would fix that by not calling suspend_set_ops(_pm_ops) when
slow_clock is NULL in patch 6 (quick and easy) or copying the whole
at91_pm_sram_init() in at91_pm_init() and handle failures from there.
--
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL for v3.19-rc6] media fixes
On Sat, Jan 24, 2015 at 1:26 AM, Mauro Carvalho Chehab wrote: > > Please pull from: > git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media > media/v3.19-4 That does not exist. The tip of that linux-media tree does match the commit you claim is the tip but that's just the unsigned 'master' branch/. The tag you list just doesn't exist at all. There's a v3.19-3, but no 4. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kmsg: lseek errors confuse glibc's dprintf
On Thu, 15 Jan 2015 17:31:32 + Mike Crowe wrote: > glibc's dprintf implementation does not work correctly with /dev/kmsg file > descriptors because glibc treats receiving EBADF and EINVAL from lseek when > trying to determine the current file position as errors. See > https://sourceware.org/bugzilla/show_bug.cgi?id=17830 > > >From what I can tell prior to Kay Sievers printk record commit > e11fea92e13fb91c50bacca799a6131c81929986, calling lseek(fd, 0, SEEK_CUR) > with such a file descriptor would not return an error. > > Prior to Kay's change, Arnd Bergmann's commit > 6038f373a3dc1f1c26496e60b6c40b164716f07e seemed to go to some lengths to > preserve the successful return code rather than returning (the perhaps more > logical) -ESPIPE. > > glibc is happy with either a successful return or -ESPIPE. > > For maximum compatibility it seems that success should be returned but > given Kay's new seek interface perhaps this isn't helpful. > > This patch ensures that such a seek succeeds: > > diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c > index 02d6b6d..b3ff6f0 100644 > --- a/kernel/printk/printk.c > +++ b/kernel/printk/printk.c > @@ -693,7 +693,7 @@ static loff_t devkmsg_llseek(struct file *file, loff_t > offset, int whence) > loff_t ret = 0; > > if (!user) > - return -EBADF; > + return (whence == SEEK_CUR) ? 0 : -EBADF; What's actually going on here? What is the significance of file->private_data==NULL and why does this code treat it as an error? > if (offset) > return -ESPIPE; > > @@ -718,6 +718,11 @@ static loff_t devkmsg_llseek(struct file *file, loff_t > offset, int whence) > user->idx = log_next_idx; > user->seq = log_next_seq; > break; > + case SEEK_CUR: > + /* For compatibility with userspace requesting the > + * current file position. */ > + ret = 0; > + break; Can we actually do something useful here? Return some value which can be fed back into SEEK_SET to restore the file position? > default: > ret = -EINVAL; > } -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 09/16] pci: add pci_iomap_range
On Wed, Jan 14, 2015 at 07:27:54PM +0200, Michael S. Tsirkin wrote:
> Virtio drivers should map the part of the BAR they need, not necessarily
> all of it.
>
> Cc: Bjorn Helgaas
> Cc: linux-...@vger.kernel.org
> Acked-by: Arnd Bergmann
> Signed-off-by: Michael S. Tsirkin
> Signed-off-by: Rusty Russell
Acked-by: Bjorn Helgaas
Sorry it took so long for me to notice these!
> ---
>
> Bjorn, can you please ack this for merging through the virtio tree?
>
> include/asm-generic/pci_iomap.h | 10 ++
> lib/pci_iomap.c | 35 ++-
> 2 files changed, 40 insertions(+), 5 deletions(-)
>
> diff --git a/include/asm-generic/pci_iomap.h b/include/asm-generic/pci_iomap.h
> index ce37349..7389c87 100644
> --- a/include/asm-generic/pci_iomap.h
> +++ b/include/asm-generic/pci_iomap.h
> @@ -15,6 +15,9 @@ struct pci_dev;
> #ifdef CONFIG_PCI
> /* Create a virtual mapping cookie for a PCI BAR (memory or IO) */
> extern void __iomem *pci_iomap(struct pci_dev *dev, int bar, unsigned long
> max);
> +extern void __iomem *pci_iomap_range(struct pci_dev *dev, int bar,
> + unsigned long offset,
> + unsigned long maxlen);
> /* Create a virtual mapping cookie for a port on a given PCI device.
> * Do not call this directly, it exists to make it easier for architectures
> * to override */
> @@ -30,6 +33,13 @@ static inline void __iomem *pci_iomap(struct pci_dev *dev,
> int bar, unsigned lon
> {
> return NULL;
> }
> +
> +static inline void __iomem *pci_iomap_range(struct pci_dev *dev, int bar,
> + unsigned long offset,
> + unsigned long maxlen)
> +{
> + return NULL;
> +}
> #endif
>
> #endif /* __ASM_GENERIC_IO_H */
> diff --git a/lib/pci_iomap.c b/lib/pci_iomap.c
> index 0d83ea8..bcce5f1 100644
> --- a/lib/pci_iomap.c
> +++ b/lib/pci_iomap.c
> @@ -10,10 +10,11 @@
>
> #ifdef CONFIG_PCI
> /**
> - * pci_iomap - create a virtual mapping cookie for a PCI BAR
> + * pci_iomap_range - create a virtual mapping cookie for a PCI BAR
> * @dev: PCI device that owns the BAR
> * @bar: BAR number
> - * @maxlen: length of the memory to map
> + * @offset: map memory at the given offset in BAR
> + * @maxlen: max length of the memory to map
> *
> * Using this function you will get a __iomem address to your device BAR.
> * You can access it using ioread*() and iowrite*(). These functions hide
> @@ -21,16 +22,21 @@
> * you expect from them in the correct way.
> *
> * @maxlen specifies the maximum length to map. If you want to get access to
> - * the complete BAR without checking for its length first, pass %0 here.
> + * the complete BAR from offset to the end, pass %0 here.
> * */
> -void __iomem *pci_iomap(struct pci_dev *dev, int bar, unsigned long maxlen)
> +void __iomem *pci_iomap_range(struct pci_dev *dev,
> + int bar,
> + unsigned long offset,
> + unsigned long maxlen)
> {
> resource_size_t start = pci_resource_start(dev, bar);
> resource_size_t len = pci_resource_len(dev, bar);
> unsigned long flags = pci_resource_flags(dev, bar);
>
> - if (!len || !start)
> + if (len <= offset || !start)
> return NULL;
> + len -= offset;
> + start += offset;
> if (maxlen && len > maxlen)
> len = maxlen;
> if (flags & IORESOURCE_IO)
> @@ -43,6 +49,25 @@ void __iomem *pci_iomap(struct pci_dev *dev, int bar,
> unsigned long maxlen)
> /* What? */
> return NULL;
> }
> +EXPORT_SYMBOL(pci_iomap_range);
>
> +/**
> + * pci_iomap - create a virtual mapping cookie for a PCI BAR
> + * @dev: PCI device that owns the BAR
> + * @bar: BAR number
> + * @maxlen: length of the memory to map
> + *
> + * Using this function you will get a __iomem address to your device BAR.
> + * You can access it using ioread*() and iowrite*(). These functions hide
> + * the details if this is a MMIO or PIO address space and will just do what
> + * you expect from them in the correct way.
> + *
> + * @maxlen specifies the maximum length to map. If you want to get access to
> + * the complete BAR without checking for its length first, pass %0 here.
> + * */
> +void __iomem *pci_iomap(struct pci_dev *dev, int bar, unsigned long maxlen)
> +{
> + return pci_iomap_range(dev, bar, 0, maxlen);
> +}
> EXPORT_SYMBOL(pci_iomap);
> #endif /* CONFIG_PCI */
> --
> MST
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 08/16] mn10300: drop dead code
On Wed, Jan 14, 2015 at 07:27:48PM +0200, Michael S. Tsirkin wrote:
> pci-iomap.c was (apparently, mistakenly) reintroduced as part of
> commit 83c2dc15ce824450e7044b9f90cd529c25747ae0
> MN10300: Handle cacheable PCI regions in pci_iomap()
> probably as side-effect of forward-porting the patch
> from an old kernel.
>
> It's not really needed: the generic pci_iomap does the right thing here.
>
> The new file isn't compiled so it's safe to drop.
>
> Cc: Bjorn Helgaas
> Cc: linux-...@vger.kernel.org
> Cc: triv...@kernel.org
> Cc: David Howells
> Signed-off-by: Michael S. Tsirkin
Acked-by: Bjorn Helgaas
> ---
>
> Can relevant people please ack this for merging through virtio tree?
>
> arch/mn10300/unit-asb2305/pci-iomap.c | 35
> ---
> 1 file changed, 35 deletions(-)
> delete mode 100644 arch/mn10300/unit-asb2305/pci-iomap.c
>
> diff --git a/arch/mn10300/unit-asb2305/pci-iomap.c
> b/arch/mn10300/unit-asb2305/pci-iomap.c
> deleted file mode 100644
> index bd65dae..000
> --- a/arch/mn10300/unit-asb2305/pci-iomap.c
> +++ /dev/null
> @@ -1,35 +0,0 @@
> -/* ASB2305 PCI I/O mapping handler
> - *
> - * Copyright (C) 2007 Red Hat, Inc. All Rights Reserved.
> - * Written by David Howells (dhowe...@redhat.com)
> - *
> - * This program is free software; you can redistribute it and/or
> - * modify it under the terms of the GNU General Public Licence
> - * as published by the Free Software Foundation; either version
> - * 2 of the Licence, or (at your option) any later version.
> - */
> -#include
> -#include
> -
> -/*
> - * Create a virtual mapping cookie for a PCI BAR (memory or IO)
> - */
> -void __iomem *pci_iomap(struct pci_dev *dev, int bar, unsigned long maxlen)
> -{
> - resource_size_t start = pci_resource_start(dev, bar);
> - resource_size_t len = pci_resource_len(dev, bar);
> - unsigned long flags = pci_resource_flags(dev, bar);
> -
> - if (!len || !start)
> - return NULL;
> -
> - if ((flags & IORESOURCE_IO) || (flags & IORESOURCE_MEM)) {
> - if (flags & IORESOURCE_CACHEABLE && !(flags & IORESOURCE_IO))
> - return ioremap(start, len);
> - else
> - return ioremap_nocache(start, len);
> - }
> -
> - return NULL;
> -}
> -EXPORT_SYMBOL(pci_iomap);
> --
> MST
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] at91: cleanup/soc for 3.20 #3
On Fri, Jan 23, 2015 at 06:15:07PM +0100, Nicolas Ferre wrote: > Arnd, Olof, Kevin, > > This is a batch of cleanup/soc modifications that you may also stack on top of > your "soc" branch as the previous one. It stabilizes a little bit our cleanup > action before going further. > I also have the feeling that multi-platform would be hard to reach for 3.20... > > Thanks, best regards, > > The following changes since commit 29ee506d0d56f6d39cc237de2512f9cb5629cbf7: > > ARM: at91: move at91rm9200_idle() to clk/at91/pmc.c (2015-01-16 18:08:42 > +0100) > > are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/nferre/linux-at91.git > tags/at91-cleanup3 > > for you to fetch changes up to d7b943cd96a1196a7e4f8ae48fc16a086ccc9a6a: > > ARM: at91: pm: remove warning to remove SOC_AT91SAM9263 usage (2015-01-23 > 12:35:50 +0100) > Hi, I had a comment on the very first patch in this branch, so please address that and send a fresh pull request. Thanks, -Olof -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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, sched: WARNING: CPU: 30 PID: 23771 at kernel/rcu/tree_plugin.h:337 rcu_read_unlock_special+0x369/0x550()
On 01/23/2015 05:54 PM, Paul E. McKenney wrote:
> On Fri, Jan 23, 2015 at 04:51:52PM -0500, Sasha Levin wrote:
>> > On 01/23/2015 04:36 AM, Paul E. McKenney wrote:
>>> > > diff --git a/kernel/rcu/tree_plugin.h b/kernel/rcu/tree_plugin.h
>>> > > index 8669de884445..ec99dc16aa38 100644
>>> > > --- a/kernel/rcu/tree_plugin.h
>>> > > +++ b/kernel/rcu/tree_plugin.h
>>> > > @@ -322,6 +322,7 @@ void rcu_read_unlock_special(struct task_struct *t)
>>> > > special = t->rcu_read_unlock_special;
>>> > > if (special.b.need_qs) {
>>> > > rcu_preempt_qs();
>>> > > + t->rcu_read_unlock_special.need_qs = false;
>> >
>> > It didn't compile, I've used:
>> >
>> >t->rcu_read_unlock_special.b.need_qs = false;
> Apologies, I should have marked it "untested". Good show on finding
> the correct fix.
>
> But does your fixed version help? ;-)
I haven't seen it happening it again, but you won't get a "yes" out of me
until tomorrow evening :)
Thanks,
Sasha
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] PCI: keystone: fix incorrect annotations on probe and remove
On Thu, Jan 08, 2015 at 02:17:36PM -0800, Dmitry Torokhov wrote:
> Even though platform bus is not hot-pluggable, devices on it can be unbound
> from the driver and bound back to it via sysfs, so we should not be using
> __init annotations on probe() and __exit annotations on remove() methods.
>
> Signed-off-by: Dmitry Torokhov
I also removed the __init annotations from ks_pcie_host_init() and
ks_add_pcie_port() and applied this to pci/host-keystone for v3.20, thanks!
> ---
>
> Not tested, found by casual code inspection.
>
> drivers/pci/host/pci-keystone.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/pci/host/pci-keystone.c b/drivers/pci/host/pci-keystone.c
> index 1b893bc..7b84e1d 100644
> --- a/drivers/pci/host/pci-keystone.c
> +++ b/drivers/pci/host/pci-keystone.c
> @@ -332,7 +332,7 @@ static const struct of_device_id ks_pcie_of_match[] = {
> };
> MODULE_DEVICE_TABLE(of, ks_pcie_of_match);
>
> -static int __exit ks_pcie_remove(struct platform_device *pdev)
> +static int ks_pcie_remove(struct platform_device *pdev)
> {
> struct keystone_pcie *ks_pcie = platform_get_drvdata(pdev);
>
> @@ -341,7 +341,7 @@ static int __exit ks_pcie_remove(struct platform_device
> *pdev)
> return 0;
> }
>
> -static int __init ks_pcie_probe(struct platform_device *pdev)
> +static int ks_pcie_probe(struct platform_device *pdev)
> {
> struct device *dev = >dev;
> struct keystone_pcie *ks_pcie;
> @@ -398,9 +398,9 @@ fail_clk:
> return ret;
> }
>
> -static struct platform_driver ks_pcie_driver __refdata = {
> +static struct platform_driver ks_pcie_driver = {
> .probe = ks_pcie_probe,
> - .remove = __exit_p(ks_pcie_remove),
> + .remove = ks_pcie_remove,
> .driver = {
> .name = "keystone-pcie",
> .owner = THIS_MODULE,
> --
> 2.2.0.rc0.207.ga3a616c
>
>
> --
> 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 0/2] add support for new persistent memory instructions
On 01/23/2015 12:40 PM, Ross Zwisler wrote:
> This patch set adds support for two new persistent memory instructions,
> pcommit
> and clwb. These instructions were announced in the document "Intel
> Architecture Instruction Set Extensions Programming Reference" with reference
> number 319433-022.
>
> https://software.intel.com/sites/default/files/managed/0d/53/319433-022.pdf
>
Please explain in these patch descriptions what the instructions
actually do.
+ volatile struct { char x[64]; } *p = __p;
+
+ asm volatile(ALTERNATIVE_2(
+ ".byte " __stringify(NOP_DS_PREFIX) "; clflush (%[pax])",
+ ".byte 0x66; clflush (%[pax])", /* clflushopt (%%rax) */
+ X86_FEATURE_CLFLUSHOPT,
+ ".byte 0x66, 0x0f, 0xae, 0x30", /* clwb (%%rax) */
+ X86_FEATURE_CLWB)
+ : [p] "+m" (*p)
+ : [pax] "a" (p));
For the specific case of CLWB, we can use an "m" input rather than a
"+m" output, simply because CLWB (or CLFLUSH* used as a standin for CLWB
doesn't need to be ordered with respect to loads (whereas CLFLUSH* do).
Now, one can argue that for performance reasons we should should still
use "+m" in case we use the CLFLUSH* standin, to avoid flushing a cache
line to memory just to bring it back in.
+static inline void pcommit(void)
+{
+ alternative(ASM_NOP4, ".byte 0x66, 0x0f, 0xae, 0xf8",
+ X86_FEATURE_PCOMMIT);
+}
+
Should we use an SFENCE as a standin if pcommit is unavailable, in case
we end up using CLFLUSHOPT?
-hpa
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: at91: fix Kconfig.debug by adding DEBUG_AT91_UART option
Hi Nicolas, On Tue, Jan 20, 2015 at 2:54 AM, Nicolas Ferre wrote: > The DEBUG_AT91_UART Kconfig option was forgotten when moving the > AT91 debug-macro.S file. Add it and use it for the at91.S compilation. > > Reported-by: Paul Bolle > Signed-off-by: Nicolas Ferre > --- > Hi Alexandre, > Please tell me if this patch makes sense to fix the lack of this > DEBUG_AT91_UART Kconfig option. > > Paul, > Thanks for the heads up. > > Bye, > Nico. > > arch/arm/Kconfig.debug | 7 +-- > 1 file changed, 5 insertions(+), 2 deletions(-) > > diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug > index e34d24949c6a..b3d388e5f4ff 100644 > --- a/arch/arm/Kconfig.debug > +++ b/arch/arm/Kconfig.debug > @@ -1164,12 +1164,15 @@ config DEBUG_STI_UART > bool > depends on ARCH_STI > > +config DEBUG_AT91_UART > + bool > + depends on ARCH_AT91 > + This is not inserted in the list alphabetically. It's not very well sorted today either, but it should probably go above exynos. Also, there are a number of configs that _select_ DEBUG_AT91_UART in the list above, but they don't depend on AT91. So what can happen is that you can select those, and then they will enable this option (which will spit out a warning about unfulfilled dependency). You should probably make the choices that select this option also depend on AT91? -Olof -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] platform-drivers-x86 for 3.19-2
Hi Linus, The support for the dell-laptop keyboard backlight was flawed and the fix: https://lkml.org/lkml/2015/1/14/539 was more invasive that I felt comfortable sending at RC5. This series reverts the support for the dell-laptop keyboard backlight as well as the documentation for the newly created sysfs attributes. We'll get this implemented correctly for 3.20. Thanks, Darren Hart Intel Open Source Technology Center The following changes since commit ec6f34e5b552fb0a52e6aae1a5afbbb1605cc6cc: Linux 3.19-rc5 (2015-01-18 18:02:20 +1200) are available in the git repository at: git://git.infradead.org/users/dvhart/linux-platform-drivers-x86.git tags/platform-drivers-x86-v3.19-2 for you to fetch changes up to b78695a71de994cdbd58f4b3be9085a60bd2203d: Revert "platform: x86: dell-laptop: Add support for keyboard backlight" (2015-01-23 11:10:32 -0800) platform-drivers-x86 for 3.19-2 dell-laptop: Revert keyboard backlight sysfs support and documentation Darren Hart (2): Revert "Documentation: Add entry for dell-laptop sysfs interface" Revert "platform: x86: dell-laptop: Add support for keyboard backlight" .../ABI/testing/sysfs-platform-dell-laptop | 60 -- drivers/platform/x86/dell-laptop.c | 1055 +--- 2 files changed, 6 insertions(+), 1109 deletions(-) delete mode 100644 Documentation/ABI/testing/sysfs-platform-dell-laptop -- Darren Hart Intel Open Source Technology Center -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 07/12] pm: at91: the standby mode uses the same sram function as the suspend to memory mode
On 23/01/2015 at 18:32:34 +0100, Sylvain Rochet wrote :
> Hello Wenyou,
>
> On Tue, Jan 20, 2015 at 04:17:00PM +0800, Wenyou Yang wrote:
> >
> > diff --git a/arch/arm/mach-at91/pm.c b/arch/arm/mach-at91/pm.c
> > index 691e6db..a1010f0 100644
> > --- a/arch/arm/mach-at91/pm.c
> > +++ b/arch/arm/mach-at91/pm.c
> (...)
> > static int at91_pm_enter(suspend_state_t state)
> > {
> > at91_pinctrl_gpio_suspend();
> >
> > switch (state) {
> > + /*
> > +* Suspend-to-RAM is like STANDBY plus slow clock mode, so
> > +* drivers must suspend more deeply, the master clock switches
> > +* to the clk32k and turns off the main oscillator
> > +*
> > +* STANDBY mode has *all* drivers suspended; ignores irqs not
> > +* marked as 'wakeup' event sources; and reduces DRAM power.
> > +* But otherwise it's identical to PM_SUSPEND_ON: cpu idle, and
> > +* nothing fancy done with main or cpu clocks.
> > +*/
> > + case PM_SUSPEND_MEM:
> > + case PM_SUSPEND_STANDBY:
>(...)
> > - case PM_SUSPEND_MEM:
> > - /*
> > -* Ensure that clocks are in a valid state.
> > -*/
> > - if (!at91_pm_verify_clocks())
> > - goto error;
>(...)
> > + if (!at91_pm_verify_clocks())
> > + goto error;
> >
>(...)
> > - case PM_SUSPEND_STANDBY:
> > - /*
> > -* NOTE: the Wait-for-Interrupt instruction needs to be
>
> By doing that at91_pm_verify_clocks() is now called for both MEM and
> STANDBY targets.
>
> In my opinion this function is misnamed and should be called
> at91_pm_verify_clocks_for_slow_clock_mode(). This function actually
> checks if we can safely switch to slow clock mode, if some peripherals
> are still using the master clock, we abort the suspend because we can't
> suspend in good condition. Hard unclocking peripherals which ask for a
> soft stop, like USB controllers, is something we should avoid doing.
>
> This function checks if USB PLL and PLL B are stopped, if PCK0..PCK3 are
> stopped too (or just using the 32k clock). If all drivers suspended
> correctly this is the state we expect and we can suspend in a deep
> state.
>
> Not this is currently not the case in linux-next, suspend/resume support
> to all Atmel USB drivers (ehci-atmel,ohci-at91,atmel_usba,at91_udc) are
> in my series:
> [PATCHv7 0/6] USB: host: Atmel OHCI and EHCI drivers improvements
><1421761144-11767-1-git-send-email-sylvain.roc...@finsecur.com>
> [PATCHv6 0/5] USB: gadget: atmel_usba_udc: Driver improvements
><1421945805-31129-1-git-send-email-sylvain.roc...@finsecur.com>
>
> We are not going to change any clock for STANDBY target, there is no
> clock to check, so we don't need to call at91_pm_verify_clocks() for
> this target.
>
I think we should actually stop checking those clocks. In the meantime,
you are right and at91_pm_verify_clocks must not be called
unconditionally.
--
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] qcom SoC changes for v3.20-2
On Fri, Jan 23, 2015 at 10:37:37AM -0600, Kumar Gala wrote: > Updated from the tags/qcom-soc-for-3.20, dropped the movement of scm > code into drivers/soc/qcom, added a few other minor scm bug fixes, > and Andy Gross as co-maintainer. > > The following changes since commit 97bf6af1f928216fd6c5a66e8a57bfa95a659672: > > Linux 3.19-rc1 (2014-12-20 17:08:50 -0800) > > are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/galak/linux-qcom.git > tags/qcom-soc-for-3.20-2 > > for you to fetch changes up to f5d3af9d21f9790ac078276e6c103871c12a3daa: > > MAINTAINERS: Add co-maintainer for ARM/Qualcomm Support (2015-01-23 > 10:29:21 -0600) Merged, thanks. -Olof -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
