Re: [PATCH V2] MIPS: change type of asid_cache to unsigned long
On 2014/5/27 13:23, Yong Zhang wrote: > On Tue, May 27, 2014 at 01:07:20PM +0800, Li Zefan wrote: >> On 2014/5/27 12:50, Yong Zhang wrote: >>> BTW, I realy don't care who credits the patch and Ralf said that >>> he will applied the one which moves the place of udelay_val. >>> >>> Anyway, if your company pays you more money if you contribute to >>> the community, just take it and talk about it with Ralf ;-) >>> >> >> We don't do contribution for money, and I don't think you do, >> but crediting properly is one of the reason that our kernel >> community keeps prosperous for so many years, and that's one >> of the reason we introduced Reported-by and Tested-by tags. > > I'll reply this email for the last time. > > To me your action is just like Reported-by, but I admit that > you also do analysis. If you don't the way change it to whatever > you want. > Sorry if I sounded offensive. I want Li Bin to get the credit, because he's supposed to, and I want him to be encouraged in contributing to the mainline kernel. The decision is on Ralf, whether to accept your patch or let us send our fix with detailed changelog. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 00/11] sched: consolidation of cpu_power
On 05/26/2014 09:24 PM, Vincent Guittot wrote: > Hi Preeti, > > I have done ebizzy tests on my platforms but doesn't have similar > results than you (my results below). It seems to be linked to SMT. I'm > going to look at that part more deeply and try to find a more suitable > HW for tests. You are right Vincent. I tested this in smt-off mode and the regression was not seen. But the regression was of the order 27% with higher number of threads in smt-on mode. What is interesting is that the regression increases in the range N=1 to N=24 and then it dips to 0 at N=48 on a 6 core, SMT 8 machine. Let me dig this further. Let me dig further. Regards Preeti U Murthy > > ebizzy -t N -S 20 > Quad cores > N tip +patchset > 1 100.00% (+/- 0.30%) 97.00% (+/- 0.42%) > 2 100.00% (+/- 0.80%) 100.48% (+/- 0.88%) > 4 100.00% (+/- 1.18%) 99.32% (+/- 1.05%) > 6 100.00% (+/- 8.54%) 98.84% (+/- 1.39%) > 8 100.00% (+/- 0.45%) 98.89% (+/- 0.91%) > 10 100.00% (+/- 0.32%) 99.25% (+/- 0.31%) > 12 100.00% (+/- 0.15%) 99.20% (+/- 0.86%) > 14 100.00% (+/- 0.58%) 99.44% (+/- 0.55%) > > Dual cores > N tip +patchset > 1 100.00% (+/- 1.70%) 99.35% (+/- 2.82%) > 2 100.00% (+/- 2.75%) 100.48% (+/- 1.51%) > 4 100.00% (+/- 2.37%) 102.63% (+/- 2.35%) > 6 100.00% (+/- 3.11%) 97.65% (+/- 1.02%) > 8 100.00% (+/- 0.26%) 103.68% (+/- 5.90%) > 10 100.00% (+/- 0.30%) 106.71% (+/- 10.85%) > 12 100.00% (+/- 1.18%) 98.95% (+/- 0.75%) > 14 100.00% (+/- 1.82%) 102.89% (+/- 2.32%) > > Regards, > Vincent > > On 26 May 2014 12:04, Vincent Guittot wrote: >> On 26 May 2014 11:44, Preeti U Murthy wrote: >>> Hi Vincent, >>> >>> I conducted test runs of ebizzy on a Power8 box which had 48 cpus. >>> 6 cores with SMT-8 to be precise. Its a single socket box. The results >>> are as below. >>> >>> On 05/23/2014 09:22 PM, Vincent Guittot wrote: Part of this patchset was previously part of the larger tasks packing patchset [1]. I have splitted the latter in 3 different patchsets (at least) to make the thing easier. -configuration of sched_domain topology [2] -update and consolidation of cpu_power (this patchset) -tasks packing algorithm SMT system is no more the only system that can have a CPUs with an original capacity that is different from the default value. We need to extend the use of cpu_power_orig to all kind of platform so the scheduler will have both the maximum capacity (cpu_power_orig/power_orig) and the current capacity (cpu_power/power) of CPUs and sched_groups. A new function arch_scale_cpu_power has been created and replace arch_scale_smt_power, which is SMT specifc in the computation of the capapcity of a CPU. During load balance, the scheduler evaluates the number of tasks that a group of CPUs can handle. The current method assumes that tasks have a fix load of SCHED_LOAD_SCALE and CPUs have a default capacity of SCHED_POWER_SCALE. This assumption generates wrong decision by creating ghost cores and by removing real ones when the original capacity of CPUs is different from the default SCHED_POWER_SCALE. Now that we have the original capacity of a CPUS and its activity/utilization, we can evaluate more accuratly the capacity of a group of CPUs. This patchset mainly replaces the old capacity method by a new one and has kept the policy almost unchanged whereas we can certainly take advantage of this new statistic in several other places of the load balance. TODO: - align variable's and field's name with the renaming [3] Tests results: I have put below results of 2 tests: - hackbench -l 500 -s 4096 - scp of 100MB file on the platform on a dual cortex-A7 hackbenchscp tip/master25.75s(+/-0.25) 5.16MB/s(+/-1.49) + patches 1,2 25.89s(+/-0.31) 5.18MB/s(+/-1.45) + patches 3-1025.68s(+/-0.22) 7.00MB/s(+/-1.88) + irq accounting 25.80s(+/-0.25) 8.06MB/s(+/-0.05) on a quad cortex-A15 hackbenchscp tip/master15.69s(+/-0.16) 9.70MB/s(+/-0.04) + patches 1,2 15.53s(+/-0.13) 9.72MB/s(+/-0.05) + patches 3-1015.56s(+/-0.22) 9.88MB/s(+/-0.05) + irq accounting 15.99s(+/-0.08) 10.37MB/s(+/-0.03) The improvement of scp bandwidth happens when tasks and irq are using different CPU which is a bit random without irq accounting config >>> >>> N -> Number of threads of ebizzy >>> >>> Each 'N' run was for 30 seconds with multiple iterations and averaging them. >>> >>> N %change in number of records >>>read after patching >>> -- >>> 1 + 0.0038 >>> 4 -17.6429 >>> 8 -26.3989 >>> 12 -29.5070 >>> 16
Re: Documenting execve() and EAGAIN
Hello Vasiliy,
On 05/26/2014 08:11 PM, Vasiliy Kulikov wrote:
> Hi Michael,
>
> On Wed, May 21, 2014 at 20:12 +0200, Michael Kerrisk (man-pages) wrote:
>> Vasily (and Motohiro),
>>
>> Sometime ago, Motohiro raised a documentation bug
>> ( https://bugzilla.kernel.org/show_bug.cgi?id=42704 ) which
>> relates to your commit 72fa59970f8698023045ab0713d66f3f4f96945c
>> ("move RLIMIT_NPROC check from set_user() to do_execve_common()")
>>
>> I have attempted to document this, and I would like to ask you
>> (and Motohiro) if you would review the text proposed below for
>> the exceve(2) man page.
>>
>> Thank you,
>>
>> Michael
>>
>>
>> ERRORS
>>EAGAIN (since Linux 3.1)
>> Having changed its real UID using one of the set*uid()
>> calls, the caller was—and is now still—above its
>> RLIMIT_NPROC resource limit (see setrlimit(2)). For a
>> more detailed explanation of this error, see NOTES.
>>
>> NOTES
>>execve() and EAGAIN
>>A more detailed explanation of the EAGAIN error that can occur
>>(since Linux 3.1) when calling execve() is as follows.
>>
>>The EAGAIN error can occur when a preceding call to setuid(2),
>>setreuid(2), or setresuid(2) caused the real user ID of the
>>process to change, and that change caused the process to
>>exceed its RLIMIT_NPROC resource limit (i.e., the number of
>>processes belonging to the new real UID exceeds the resource
>>limit). In Linux 3.0 and earlier, this caused the set*uid()
>>call to fail.
>>
>>Since Linux 3.1, the scenario just described no longer causes
>>the set*uid() call to fail, because it too often led to secu‐
>>rity holes because buggy applications didn't check the return
>>status and assumed that—if the caller had root privileges—the
>>call would always succeed. Instead, the set*uid() calls now
>>successfully change real UID, but the kernel sets an internal
>>flag, named PF_NPROC_EXCEEDED, to note that the RLIMIT_NPROC
>>resource limit has been exceeded. If the resource limit is
>>still exceeded at the time of a subsequent execve() call, that
>>call fails with the error EAGAIN. This kernel logic ensures
>>that the RLIMIT_NPROC resource limit is still enforced for the
>>common privileged daemon workflow—namely, fork(2)+ set*uid()+
>>execve(2).
>>
>>If the resource limit was not still exceeded at the time of
>>the execve() call (because other processes belonging to this
>>real UID terminated between the set*uid() call and the
>>execve() call), then the execve() call succeeds and the kernel
>>clears the PF_NPROC_EXCEEDED process flag. The flag is also
>>cleared if a subsequent call to fork(2) by this process suc‐
>>ceeds.
>
> Probably explicitly state that NPROC check on execve() is processed only
> in case of a previous set*uid() call? If there was no previous
> set*uid() call the semantics of execve() checks are the same as before
> (IOW, RLIMIT_NPROC is ignored).
Yes, good idea. I'll add some words to make that clearer.
> The rest is fine.
Thanks for checking it!
Cheers,
Michael
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 linux-next] DRM: Armada: update dma_buf_export use
On 26 May 2014 09:06, Stephen Rothwell wrote: > Hi all, > > On Sun, 25 May 2014 23:54:35 +0100 Russell King - ARM Linux > wrote: >> >> On Sun, May 25, 2014 at 02:08:48PM +0200, David Herrmann wrote: >> > >> > On Sat, May 24, 2014 at 11:05 PM, Vincent Stehlé >> > wrote: >> > > The dma_buf_export function was updated in commit 4bcec44ffaf9 'dma-buf: >> > > use >> > > reservation objects' to take a reservation object parameter; update >> > > Armada >> > > export method accordingly. >> > > >> > > This fixes the following compilation error: >> > > >> > > drivers/gpu/drm/armada/armada_gem.c: In function >> > > ‘armada_gem_prime_export’: >> > > drivers/gpu/drm/armada/armada_gem.c:544:16: error: macro >> > > "dma_buf_export" requires 5 arguments, but only 4 given >> > > >> > > Signed-off-by: Vincent Stehlé >> > > Cc: Russell King >> > > Cc: David Airlie >> > > Cc: Maarten Lankhorst >> > > Cc: Sumit Semwal >> > >> > Reviewed-by: David Herrmann >> >> Acked-by: Russell King >> >> Airlied, can you merge this please? Thanks. > > Except that commit 4bcec44ffaf9 'dma-buf: use reservation objects' > comes from the dma-buf tree, so Sumit needs to add this commit to his > tree. > Then we should cc him. Dave. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] regulator: ltc3589: Fix module dependency
Make this driver depend on I2C and select REGMAP_I2C to fix build failure. Also allows this driver to be built as module. Reported-by: Stephen Rothwell Signed-off-by: Axel Lin --- drivers/regulator/Kconfig | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig index 8f5c880..c2fa0b4 100644 --- a/drivers/regulator/Kconfig +++ b/drivers/regulator/Kconfig @@ -273,7 +273,9 @@ config REGULATOR_LP8788 This driver supports LP8788 voltage regulator chip. config REGULATOR_LTC3589 - bool "LTC3589 8-output voltage regulator" + tristate "LTC3589 8-output voltage regulator" + depends on I2C + select REGMAP_I2C help This enables support for the LTC3589, LTC3589-1, and LTC3589-2 8-output regulators controlled via I2C. -- 1.8.3.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Staging: rtl8192u: r8180_93cx6.c & r8192U_wx.c fix checkpatch.pl errors and warnings
Fixed the following:
ERROR: do not use C99 // comments
ERROR: else should follow close brace '}'
ERROR: need consistent spacing around '*' (ctx:WxV)
ERROR: need consistent spacing around '|' (ctx:VxW)
ERROR: space prohibited after that open parenthesis '('
ERROR: space prohibited before that '--' (ctx:WxO)
ERROR: space prohibited before that close parenthesis ')'
ERROR: space required after that ',' (ctx:VxV)
ERROR: space required after that ';' (ctx:VxV)
ERROR: space required after that close brace '}'
ERROR: space required before the open brace '{'
ERROR: space required before the open parenthesis '('
ERROR: spaces required around that '!=' (ctx:VxV)
ERROR: spaces required around that '!=' (ctx:WxV)
ERROR: spaces required around that '&&' (ctx:VxV)
ERROR: spaces required around that '<' (ctx:VxV)
ERROR: spaces required around that '=' (ctx:VxV)
ERROR: spaces required around that '=' (ctx:VxW)
ERROR: spaces required around that '=' (ctx:WxV)
ERROR: spaces required around that '==' (ctx:VxV)
ERROR: that open brace { should be on the previous line
ERROR: trailing statements should be on next line
WARNING: Missing a blank line after declarations
WARNING: missing space after struct definition
WARNING: please, no spaces at the start of a line
WARNING: suspect code indent for conditional statements (16, 16)
Signed-off-by: Chaitanya Hazarey
---
drivers/staging/rtl8192u/r8180_93cx6.c | 58 ++---
drivers/staging/rtl8192u/r8192U_wx.c | 373 +---
2 files changed, 223 insertions(+), 208 deletions(-)
diff --git a/drivers/staging/rtl8192u/r8180_93cx6.c
b/drivers/staging/rtl8192u/r8180_93cx6.c
index cd06054..7a0051e 100644
--- a/drivers/staging/rtl8192u/r8180_93cx6.c
+++ b/drivers/staging/rtl8192u/r8180_93cx6.c
@@ -53,7 +53,7 @@ static void eprom_ck_cycle(struct net_device *dev)
}
-static void eprom_w(struct net_device *dev,short bit)
+static void eprom_w(struct net_device *dev, short bit)
{
u8 cmdreg;
@@ -86,7 +86,7 @@ static void eprom_send_bits_string(struct net_device *dev,
short b[], int len)
{
int i;
- for(i=0; iepromtype==EPROM_93c56){
- addr_str[7]=addr & 1;
- addr_str[6]=addr & (1<<1);
- addr_str[5]=addr & (1<<2);
- addr_str[4]=addr & (1<<3);
- addr_str[3]=addr & (1<<4);
- addr_str[2]=addr & (1<<5);
- addr_str[1]=addr & (1<<6);
- addr_str[0]=addr & (1<<7);
- addr_len=8;
- }else{
- addr_str[5]=addr & 1;
- addr_str[4]=addr & (1<<1);
- addr_str[3]=addr & (1<<2);
- addr_str[2]=addr & (1<<3);
- addr_str[1]=addr & (1<<4);
- addr_str[0]=addr & (1<<5);
- addr_len=6;
+ if (priv->epromtype == EPROM_93c56) {
+ addr_str[7] = addr & 1;
+ addr_str[6] = addr & (1<<1);
+ addr_str[5] = addr & (1<<2);
+ addr_str[4] = addr & (1<<3);
+ addr_str[3] = addr & (1<<4);
+ addr_str[2] = addr & (1<<5);
+ addr_str[1] = addr & (1<<6);
+ addr_str[0] = addr & (1<<7);
+ addr_len = 8;
+ } else {
+ addr_str[5] = addr & 1;
+ addr_str[4] = addr & (1<<1);
+ addr_str[3] = addr & (1<<2);
+ addr_str[2] = addr & (1<<3);
+ addr_str[1] = addr & (1<<4);
+ addr_str[0] = addr & (1<<5);
+ addr_len = 6;
}
eprom_cs(dev, 1);
eprom_ck_cycle(dev);
eprom_send_bits_string(dev, read_cmd, 3);
eprom_send_bits_string(dev, addr_str, addr_len);
- //keep chip pin D to low state while reading.
- //I'm unsure if it is necessary, but anyway shouldn't hurt
+ /* keep chip pin D to low state while reading.*/
+ /* I'm unsure if it is necessary, but anyway shouldn't hurt*/
eprom_w(dev, 0);
- for(i=0;i<16;i++){
- //eeprom needs a clk cycle between writing opcode
- //and reading data. (eeprom outs a dummy 0)
+ for (i = 0 ; i < 16 ; i++) {
+ /* eeprom needs a clk cycle between writing opcode */
+ /* and reading data. (eeprom outs a dummy 0) */
eprom_ck_cycle(dev);
ret |= (eprom_r(dev)<<(15-i));
}
@@ -147,7 +147,7 @@ u32 eprom_read(struct net_device *dev, u32 addr)
eprom_cs(dev, 0);
eprom_ck_cycle(dev);
- //disable EPROM programming
+ /* disable EPROM programming */
write_nic_byte_E(dev, EPROM_CMD,
(EPROM_CMD_NORMALieee80211, a, wrqu, b);
}
static int r8192_wx_get_mode(struct net_device *dev, struct iw_request_info *a,
union iwreq_data *wrqu, char *b)
{
- struct r8192_priv *priv=ieee80211_priv(dev);
+
Re: [PATCH] Staging: rtl8192u: r8180_93cx6.c & r8192U_wx.c fix checkpatch.pl errors and warnings
Please ignore this.
Chaitanya
On Mon, May 26, 2014 at 10:32 PM, Chaitanya Hazarey wrote:
> Fixed the following:
>
> WARNING: line over 80 characters
> ERROR: do not use C99 // comments
> ERROR: else should follow close brace '}'
> ERROR: space required after that ',' (ctx:VxV)
> ERROR: space required after that ';' (ctx:VxV)
> WARNING: missing space after struct definition
> ERROR: space required before the open brace '{'
> ERROR: spaces required around that '=' (ctx:VxV)
> WARNING: Missing a blank line after declarations
> ERROR: spaces required around that '=' (ctx:VxW)
> ERROR: spaces required around that '=' (ctx:WxV)
> ERROR: space required after that close brace '}'
> ERROR: spaces required around that '<' (ctx:VxV)
> ERROR: trailing statements should be on next line
> ERROR: spaces required around that '==' (ctx:VxV)
> ERROR: spaces required around that '!=' (ctx:WxV)
> ERROR: spaces required around that '&&' (ctx:VxV)
> WARNING: please, no spaces at the start of a line
> ERROR: spaces required around that '!=' (ctx:VxV)
> ERROR: space prohibited before that '--' (ctx:WxO)
> ERROR: need consistent spacing around '|' (ctx:VxW)
> ERROR: need consistent spacing around '*' (ctx:WxV)
> ERROR: space required before the open parenthesis '('
> WARNING: printk() should include KERN_ facility level
> ERROR: space prohibited after that open parenthesis '('
> ERROR: that open brace { should be on the previous line
> ERROR: space prohibited before that close parenthesis ')'
> WARNING: suspect code indent for conditional statements (16, 16)
> WARNING: __func__ should be used instead of gcc specific __FUNCTION__
>
> Signed-off-by: Chaitanya Hazarey
> ---
> drivers/staging/rtl8192u/r8180_93cx6.c | 58 ++---
> drivers/staging/rtl8192u/r8192U_wx.c | 373
> +---
> 2 files changed, 223 insertions(+), 208 deletions(-)
>
> diff --git a/drivers/staging/rtl8192u/r8180_93cx6.c
> b/drivers/staging/rtl8192u/r8180_93cx6.c
> index cd06054..7a0051e 100644
> --- a/drivers/staging/rtl8192u/r8180_93cx6.c
> +++ b/drivers/staging/rtl8192u/r8180_93cx6.c
> @@ -53,7 +53,7 @@ static void eprom_ck_cycle(struct net_device *dev)
> }
>
>
> -static void eprom_w(struct net_device *dev,short bit)
> +static void eprom_w(struct net_device *dev, short bit)
> {
> u8 cmdreg;
>
> @@ -86,7 +86,7 @@ static void eprom_send_bits_string(struct net_device *dev,
> short b[], int len)
> {
> int i;
>
> - for(i=0; i + for (i = 0 ; i < len ; i++) {
> eprom_w(dev, b[i]);
> eprom_ck_cycle(dev);
> }
> @@ -96,50 +96,50 @@ static void eprom_send_bits_string(struct net_device
> *dev, short b[], int len)
> u32 eprom_read(struct net_device *dev, u32 addr)
> {
> struct r8192_priv *priv = ieee80211_priv(dev);
> - short read_cmd[]={1,1,0};
> + short read_cmd[] = {1, 1, 0};
> short addr_str[8];
> int i;
> int addr_len;
> u32 ret;
>
> - ret=0;
> - //enable EPROM programming
> + ret = 0;
> + /* enable EPROM programming */
> write_nic_byte_E(dev, EPROM_CMD,
>(EPROM_CMD_PROGRAM< force_pci_posting(dev);
> udelay(EPROM_DELAY);
>
> - if (priv->epromtype==EPROM_93c56){
> - addr_str[7]=addr & 1;
> - addr_str[6]=addr & (1<<1);
> - addr_str[5]=addr & (1<<2);
> - addr_str[4]=addr & (1<<3);
> - addr_str[3]=addr & (1<<4);
> - addr_str[2]=addr & (1<<5);
> - addr_str[1]=addr & (1<<6);
> - addr_str[0]=addr & (1<<7);
> - addr_len=8;
> - }else{
> - addr_str[5]=addr & 1;
> - addr_str[4]=addr & (1<<1);
> - addr_str[3]=addr & (1<<2);
> - addr_str[2]=addr & (1<<3);
> - addr_str[1]=addr & (1<<4);
> - addr_str[0]=addr & (1<<5);
> - addr_len=6;
> + if (priv->epromtype == EPROM_93c56) {
> + addr_str[7] = addr & 1;
> + addr_str[6] = addr & (1<<1);
> + addr_str[5] = addr & (1<<2);
> + addr_str[4] = addr & (1<<3);
> + addr_str[3] = addr & (1<<4);
> + addr_str[2] = addr & (1<<5);
> + addr_str[1] = addr & (1<<6);
> + addr_str[0] = addr & (1<<7);
> + addr_len = 8;
> + } else {
> + addr_str[5] = addr & 1;
> + addr_str[4] = addr & (1<<1);
> + addr_str[3] = addr & (1<<2);
> + addr_str[2] = addr & (1<<3);
> + addr_str[1] = addr & (1<<4);
> + addr_str[0] = addr & (1<<5);
> + addr_len = 6;
> }
> eprom_cs(dev, 1);
> eprom_ck_cycle(dev);
> eprom_send_bits_string(dev, read_cmd, 3);
> eprom_send_bits_string(dev, addr_str, addr_len);
>
> - //keep chip pin D to low state
Re: [PATCH v4] gpio: Add support for Intel SoC PMIC (Crystal Cove)
On Fri, May 23, 2014 at 11:00 AM, Zhu, Lejun wrote: > Devices based on Intel SoC products such as Baytrail have a Power > Management IC. In the PMIC there are subsystems for voltage regulation, > A/D conversion, GPIO and PWMs. The PMIC in Baytrail-T platform is called > Crystal Cove. > > This patch adds support for the GPIO function in Crystal Cove. A few minor comments below in case you make another version, but overall looks pretty good to me. Reviewed-by: Alexandre Courbot > > v2: > - Use IRQ chip helper to provide irqdomain. > - Implement .remove and can now build as a module. > - Various fix for unreadable or ugly code pieces. > v3: > - More fix in irq_handler and probe. > v4: > - Minor fix of one return statement. > > Signed-off-by: Yang, Bin > Signed-off-by: Zhu, Lejun > Reviewed-by: Mika Westerberg > --- > drivers/gpio/Kconfig| 13 ++ > drivers/gpio/Makefile | 1 + > drivers/gpio/gpio-crystalcove.c | 345 > > 3 files changed, 359 insertions(+) > create mode 100644 drivers/gpio/gpio-crystalcove.c > > diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig > index a86c49a..fed08d9d 100644 > --- a/drivers/gpio/Kconfig > +++ b/drivers/gpio/Kconfig > @@ -440,6 +440,19 @@ config GPIO_ARIZONA > help > Support for GPIOs on Wolfson Arizona class devices. > > +config GPIO_CRYSTAL_COVE > + tristate "GPIO support for Crystal Cove PMIC" > + depends on INTEL_SOC_PMIC > + select GPIOLIB_IRQCHIP > + help > + Support for GPIO pins on Crystal Cove PMIC. > + > + Say Yes if you have a Intel SoC based tablet with Crystal Cove PMIC > + inside. > + > + This driver can also be built as a module. If so, the module will be > + called gpio-crystalcove. > + > config GPIO_LP3943 > tristate "TI/National Semiconductor LP3943 GPIO expander" > depends on MFD_LP3943 > diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile > index 6309aff..e6cd935 100644 > --- a/drivers/gpio/Makefile > +++ b/drivers/gpio/Makefile > @@ -20,6 +20,7 @@ obj-$(CONFIG_GPIO_BCM_KONA) += gpio-bcm-kona.o > obj-$(CONFIG_GPIO_BT8XX) += gpio-bt8xx.o > obj-$(CONFIG_GPIO_CLPS711X)+= gpio-clps711x.o > obj-$(CONFIG_GPIO_CS5535) += gpio-cs5535.o > +obj-$(CONFIG_GPIO_CRYSTAL_COVE)+= gpio-crystalcove.o > obj-$(CONFIG_GPIO_DA9052) += gpio-da9052.o > obj-$(CONFIG_GPIO_DA9055) += gpio-da9055.o > obj-$(CONFIG_GPIO_DAVINCI) += gpio-davinci.o > diff --git a/drivers/gpio/gpio-crystalcove.c b/drivers/gpio/gpio-crystalcove.c > new file mode 100644 > index 000..76b6d57 > --- /dev/null > +++ b/drivers/gpio/gpio-crystalcove.c > @@ -0,0 +1,345 @@ > +/* > + * gpio-crystalcove.c - Intel Crystal Cove GPIO Driver > + * > + * Copyright (C) 2012, 2014 Intel Corporation. All rights reserved. > + * > + * This program is free software; you can redistribute it and/or > + * modify it under the terms of the GNU General Public License version > + * 2 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. > + * > + * Author: Yang, Bin > + */ > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +#define NUM_GPIO 16 > + > +#define UPDATE_TYPEBIT(0) > +#define UPDATE_MASKBIT(1) > + > +#define GPIO0IRQ 0x0b > +#define GPIO1IRQ 0x0c > +#define MGPIO0IRQS00x19 > +#define MGPIO1IRQS00x1a > +#define MGPIO0IRQSX0x1b > +#define MGPIO1IRQSX0x1c > +#define GPIO0P0CTLO0x2b > +#define GPIO0P0CTLI0x33 > +#define GPIO1P0CTLO0x3b > +#define GPIO1P0CTLI0x43 > + > +#define CTLI_INTCNT_NE (1 << 1) > +#define CTLI_INTCNT_PE (2 << 1) > +#define CTLI_INTCNT_BE (3 << 1) > + > +#define CTLO_DIR_OUT (1 << 5) > + > +#define CTLO_DRV_CMOS (0 << 4) > +#define CTLO_DRV_OD(1 << 4) > + > +#define CTLO_DRV_REN (1 << 3) > + > +#define CTLO_RVAL_2KDW (0) > +#define CTLO_RVAL_2KUP (1 << 1) > +#define CTLO_RVAL_50KDW(2 << 1) > +#define CTLO_RVAL_50KUP(3 << 1) > + > +#define CTLO_INPUT_DEF (CTLO_DRV_CMOS | CTLO_DRV_REN | CTLO_RVAL_2KUP) > +#define CTLO_OUTPUT_DEF(CTLO_DIR_OUT | CTLO_INPUT_DEF) > + > +#define GPIO_TO_CTL(gpio, dir) \ > + ((gpio < 8 ? GPIO0P0CTL ## dir : GPIO1P0CTL ## dir) + (gpio % 8)) > + > +/** > + * struct crystalcove_gpio - Crystal Cove GPIO controller > + * @buslock: for bus lock/sync and unlock. > + * @chip: the
Re: [PATCH v2] ALSA: hda: fix tegra build
At Mon, 26 May 2014 21:15:20 +0200,
Arnd Bergmann wrote:
>
> When CONFIG_PM is disabled, the CONFIG_SND_HDA_POWER_SAVE_DEFAULT symbol
> does not get defined, which causes a build error for the hda-tegra driver:
>
> hda/hda_tegra.c:80:25: error: 'CONFIG_SND_HDA_POWER_SAVE_DEFAULT' undeclared
> here (not in a function)
> static int power_save = CONFIG_SND_HDA_POWER_SAVE_DEFAULT;
> ^
> /git/arm-soc/sound/pci/hda/hda_tegra.c:235:13: warning:
> 'hda_tegra_disable_clocks' defined but not used [-Wunused-function]
> static void hda_tegra_disable_clocks(struct hda_tegra *data)
> ^
>
> This works around the problem by not referencing that macro
> when CONFIG_PM is disabled. Instead, we assume that it's disabled
> unconditionally and cannot be enabled at runtime.
>
> Signed-off-by: Arnd Bergmann
> Cc: Dylan Reid
> Cc: Stephen Warren
> Cc: Takashi Iwai
> ---
> Same patch, but this time with correct Signed-off-by line.
Thanks, applied now.
Takashi
>
> diff --git a/sound/pci/hda/hda_tegra.c b/sound/pci/hda/hda_tegra.c
> index 086fd06..a366ba9 100644
> --- a/sound/pci/hda/hda_tegra.c
> +++ b/sound/pci/hda/hda_tegra.c
> @@ -77,10 +77,14 @@ struct hda_tegra {
> void __iomem *regs;
> };
>
> +#ifdef CONFIG_PM
> static int power_save = CONFIG_SND_HDA_POWER_SAVE_DEFAULT;
> module_param(power_save, bint, 0644);
> MODULE_PARM_DESC(power_save,
>"Automatic power-saving timeout (in seconds, 0 = disable).");
> +#else
> +static int power_save = 0;
> +#endif
>
> /*
> * DMA page allocation ops.
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: rtl8192u: r8180_93cx6.c & r8192U_wx.c fix checkpatch.pl errors and warnings
Fixed the following:
WARNING: line over 80 characters
ERROR: do not use C99 // comments
ERROR: else should follow close brace '}'
ERROR: space required after that ',' (ctx:VxV)
ERROR: space required after that ';' (ctx:VxV)
WARNING: missing space after struct definition
ERROR: space required before the open brace '{'
ERROR: spaces required around that '=' (ctx:VxV)
WARNING: Missing a blank line after declarations
ERROR: spaces required around that '=' (ctx:VxW)
ERROR: spaces required around that '=' (ctx:WxV)
ERROR: space required after that close brace '}'
ERROR: spaces required around that '<' (ctx:VxV)
ERROR: trailing statements should be on next line
ERROR: spaces required around that '==' (ctx:VxV)
ERROR: spaces required around that '!=' (ctx:WxV)
ERROR: spaces required around that '&&' (ctx:VxV)
WARNING: please, no spaces at the start of a line
ERROR: spaces required around that '!=' (ctx:VxV)
ERROR: space prohibited before that '--' (ctx:WxO)
ERROR: need consistent spacing around '|' (ctx:VxW)
ERROR: need consistent spacing around '*' (ctx:WxV)
ERROR: space required before the open parenthesis '('
WARNING: printk() should include KERN_ facility level
ERROR: space prohibited after that open parenthesis '('
ERROR: that open brace { should be on the previous line
ERROR: space prohibited before that close parenthesis ')'
WARNING: suspect code indent for conditional statements (16, 16)
WARNING: __func__ should be used instead of gcc specific __FUNCTION__
Signed-off-by: Chaitanya Hazarey
---
drivers/staging/rtl8192u/r8180_93cx6.c | 58 ++---
drivers/staging/rtl8192u/r8192U_wx.c | 373 +---
2 files changed, 223 insertions(+), 208 deletions(-)
diff --git a/drivers/staging/rtl8192u/r8180_93cx6.c
b/drivers/staging/rtl8192u/r8180_93cx6.c
index cd06054..7a0051e 100644
--- a/drivers/staging/rtl8192u/r8180_93cx6.c
+++ b/drivers/staging/rtl8192u/r8180_93cx6.c
@@ -53,7 +53,7 @@ static void eprom_ck_cycle(struct net_device *dev)
}
-static void eprom_w(struct net_device *dev,short bit)
+static void eprom_w(struct net_device *dev, short bit)
{
u8 cmdreg;
@@ -86,7 +86,7 @@ static void eprom_send_bits_string(struct net_device *dev,
short b[], int len)
{
int i;
- for(i=0; iepromtype==EPROM_93c56){
- addr_str[7]=addr & 1;
- addr_str[6]=addr & (1<<1);
- addr_str[5]=addr & (1<<2);
- addr_str[4]=addr & (1<<3);
- addr_str[3]=addr & (1<<4);
- addr_str[2]=addr & (1<<5);
- addr_str[1]=addr & (1<<6);
- addr_str[0]=addr & (1<<7);
- addr_len=8;
- }else{
- addr_str[5]=addr & 1;
- addr_str[4]=addr & (1<<1);
- addr_str[3]=addr & (1<<2);
- addr_str[2]=addr & (1<<3);
- addr_str[1]=addr & (1<<4);
- addr_str[0]=addr & (1<<5);
- addr_len=6;
+ if (priv->epromtype == EPROM_93c56) {
+ addr_str[7] = addr & 1;
+ addr_str[6] = addr & (1<<1);
+ addr_str[5] = addr & (1<<2);
+ addr_str[4] = addr & (1<<3);
+ addr_str[3] = addr & (1<<4);
+ addr_str[2] = addr & (1<<5);
+ addr_str[1] = addr & (1<<6);
+ addr_str[0] = addr & (1<<7);
+ addr_len = 8;
+ } else {
+ addr_str[5] = addr & 1;
+ addr_str[4] = addr & (1<<1);
+ addr_str[3] = addr & (1<<2);
+ addr_str[2] = addr & (1<<3);
+ addr_str[1] = addr & (1<<4);
+ addr_str[0] = addr & (1<<5);
+ addr_len = 6;
}
eprom_cs(dev, 1);
eprom_ck_cycle(dev);
eprom_send_bits_string(dev, read_cmd, 3);
eprom_send_bits_string(dev, addr_str, addr_len);
- //keep chip pin D to low state while reading.
- //I'm unsure if it is necessary, but anyway shouldn't hurt
+ /* keep chip pin D to low state while reading.*/
+ /* I'm unsure if it is necessary, but anyway shouldn't hurt*/
eprom_w(dev, 0);
- for(i=0;i<16;i++){
- //eeprom needs a clk cycle between writing opcode
- //and reading data. (eeprom outs a dummy 0)
+ for (i = 0 ; i < 16 ; i++) {
+ /* eeprom needs a clk cycle between writing opcode */
+ /* and reading data. (eeprom outs a dummy 0) */
eprom_ck_cycle(dev);
ret |= (eprom_r(dev)<<(15-i));
}
@@ -147,7 +147,7 @@ u32 eprom_read(struct net_device *dev, u32 addr)
eprom_cs(dev, 0);
eprom_ck_cycle(dev);
- //disable EPROM programming
+ /* disable EPROM programming */
write_nic_byte_E(dev, EPROM_CMD,
(EPROM_CMD_NORMALieee80211, a, wrqu, b);
}
static int r8192_wx_get_mode(struct net_device
[PATCH] This is my first commit
From: kevin
---
gtserio.c | 188 ++
1 file changed, 188 insertions(+)
create mode 100755 gtserio.c
diff --git a/gtserio.c b/gtserio.c
new file mode 100755
index 000..24f1e00
--- /dev/null
+++ b/gtserio.c
@@ -0,0 +1,188 @@
+/*
+ * gtserio.c - Create an input/output character device for GeneralTouch
serial screen
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+//#include
+
+#define MAJOR_NUM 100
+#define MAJOR_MIN 0
+#define SUCCESS0
+#define DEVICE_NAME"general_touch_serial"
+#define BUF_LEN80
+MODULE_AUTHOR("GeneralTouch ");
+MODULE_DESCRIPTION(DEVICE_NAME);
+MODULE_LICENSE("GPL");
+static int Device_Open = 0;
+struct input_dev *devq;
+char Message[BUF_LEN];
+dev_t gts_t;
+unsigned char val[10];
+int gtsdata[4];
+unsigned long min_x = 0;
+unsigned long max_x = 32767;
+unsigned long min_y = 0;
+unsigned long max_y = 32767;
+
+char *Message_Ptr;
+struct class *gts_class;
+
+static int device_open(struct inode *inode, struct file *file)
+{
+ printk("GTS device_open(%p)\n", file);
+
+#ifdef DEBUG
+ printk("device_open(%p)\n", file);
+#endif
+
+ /*
+* We don't want to talk to two processes at the same time
+*/
+ if (Device_Open)
+ return -EBUSY;
+
+ Device_Open++;
+ /*
+* Initialize the message
+*/
+ Message_Ptr = Message;
+ return SUCCESS;
+}
+
+static int device_release(struct inode *inode, struct file *file)
+{
+#ifdef DEBUG
+ printk("device_release(%p,%p)\n", inode, file);
+#endif
+
+ /*
+* We're now ready for our next caller
+*/
+ Device_Open--;
+
+ module_put(THIS_MODULE);
+ return SUCCESS;
+}
+
+/*
+ * This function is called whenever a process which has already opened the
+ * device file attempts to read from it.
+ */
+static ssize_t device_read(struct file *file,
+ char __user * buffer, size_t length, loff_t * offset)
+{
+
+ return 0;
+}
+
+static ssize_t
+device_write(struct file *file,
+const char __user * buffer, size_t length, loff_t * offset)
+{
+#ifdef DEBUG
+ printk("device_write(%p,%s,%d)", file, buffer, length);
+#endif
+
+ if (copy_from_user(, buffer, length)) {
+ length = -EFAULT;
+ }
+
+ printk("val[3] = %x,val[4] = %x\nval[5] = %x,val[6] = %x\n", val[3],
+ val[4], val[5], val[6]);
+ gtsdata[0] = val[2];
+ gtsdata[1] = (val[4] << 8) | (val[3]);
+ gtsdata[2] = (val[6] << 8) | (val[5]);
+ gtsdata[3] = val[9];
+ printk("gtsdata[1] = %x\ngtsdata[2] = %x\n", gtsdata[1], gtsdata[2]);
+ input_report_abs(devq, ABS_X, gtsdata[1]);
+ input_report_abs(devq, ABS_Y, gtsdata[2]);
+ if (gtsdata[0] == 0x81) {
+
+ input_report_key(devq, BTN_TOUCH, 1);
+ input_report_abs(devq, ABS_PRESSURE, 1);
+ input_sync(devq);
+ }
+ if (gtsdata[0] == 0x84) {
+ input_report_key(devq, BTN_TOUCH, 0);
+ input_report_abs(devq, ABS_PRESSURE, 0);
+ input_sync(devq);
+ }
+ input_sync(devq);
+
+ return length;
+}
+
+struct file_operations Fops = {
+ .read = device_read,
+ .write = device_write,
+ .open = device_open,
+ .release = device_release, /* a.k.a. close */
+};
+
+/*
+ * Initialize the module - Register the character device
+ */
+static int __init gts_init(void)
+{
+ int ret_val;
+ struct input_dev *gts_dev;
+ int err1;
+ gts_t = MKDEV(MAJOR_NUM, MAJOR_MIN);
+
+ gts_class = class_create(THIS_MODULE, "gts_class");
+ device_create(gts_class, NULL, gts_t, NULL, DEVICE_NAME);
+ ret_val = register_chrdev(MAJOR_NUM, DEVICE_NAME, );
+
+ if (ret_val < 0) {
+ printk("%s failed with %d\n",
+ "Sorry, registering the character device ", ret_val);
+ return ret_val;
+ }
+
+ gts_dev = input_allocate_device();
+ if (!gts_dev) {
+ err1 = -ENOMEM;
+ goto fail1;
+ }
+ gts_dev->name = "GeneralTouch Serial TouchScreen";
+ gts_dev->phys = "generaltouch/input0";
+ gts_dev->id.bustype = BUS_RS232;
+ gts_dev->id.vendor = (int)("GT_SERIAL");
+ gts_dev->id.product = (int)("GT_SERIAL");
+ gts_dev->id.version = 0x0100;
+ gts_dev->evbit[0] =
+ BIT_MASK(EV_SYN) | BIT_MASK(EV_KEY) | BIT_MASK(EV_ABS);
+ gts_dev->keybit[BIT_WORD(BTN_TOUCH)] = BIT_MASK(BTN_TOUCH);
+
+ input_set_abs_params(gts_dev, ABS_X, min_x, max_x, 0, 0);
+ input_set_abs_params(gts_dev, ABS_Y, min_y, max_y, 0, 0);
+
+ err1 = input_register_device(gts_dev);
+ devq = gts_dev;
+fail1: input_free_device(gts_dev);
+ return err1;
+}
+
+static void __exit
Re: [PATCH V2] MIPS: change type of asid_cache to unsigned long
On Tue, May 27, 2014 at 01:07:20PM +0800, Li Zefan wrote: > On 2014/5/27 12:50, Yong Zhang wrote: > > BTW, I realy don't care who credits the patch and Ralf said that > > he will applied the one which moves the place of udelay_val. > > > > Anyway, if your company pays you more money if you contribute to > > the community, just take it and talk about it with Ralf ;-) > > > > We don't do contribution for money, and I don't think you do, > but crediting properly is one of the reason that our kernel > community keeps prosperous for so many years, and that's one > of the reason we introduced Reported-by and Tested-by tags. I'll reply this email for the last time. To me your action is just like Reported-by, but I admit that you also do analysis. If you don't the way change it to whatever you want. Thanks, Yong -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 4/4] KVM: x86: get CPL from SS.DPL
>> >> >> Is this specified anywhere in SDM as a requirement for x86 OS? If so, >> maybe provide a pointer to support this. > > > In the case of the Intel manuals, it mentions in several places that > SS.DPL=CPL. All the mentions are in the VMX sections of the manual, though > I've found non-Intel material saying that system-management mode also used > SS.DPL as the CPL: > > * "SS.DPL corresponds to the logical processor’s current privilege level > (CPL)" (footnote in 26.3.1.5 Checks on Guest Non-Register State). > > * "SS.DPL is always loaded from the SS access-rights field. This will be the > current privilege level (CPL) after the VM entry completes" (26.3.2.2 > Loading Guest Segment Registers and Descriptor-Table Registers) > > * "VMX-critical state [...] consists of the following: (1) SS.DPL (the > current privilege level);" (34.14.1 Default Treatment of SMI delivery [in > VMX mode]). > > Instead, AMD says that "the SS segment base, limit and attributes are not > modified" by sysret. It almost looks as if AMD processors never use SS.DPL; > almost because searching "SS.attr" in the AMD manuals shows that the > processor does write to SS.attr sometimes. In the SVM documentation, it > says "The processor reads the current privilege level from the CPL field in > the VMCB, not from SS.DPL. However, SS.DPL should match the CPL field" and > sneakily leaves out what happens if they do not match... My guess is that SS.DPL==CPL will fail during VMRUN. This can be quickly tested by slightly tweaking VMCB content of a regular VM. > > >>> case of SYSRET on AMD processors, which sets SS.DPL=SS.RPL from the >>> value in the STAR MSR, but force CPL=3 (Intel instead forces >>> SS.DPL=SS.RPL=CPL=3). >> >> >> Thinking out loud here... Should we force SYSRET SS.RPL to be 3 when >> VM updates STAR MSR? Following the same thought, does it make sense to >> check (and force) SS.DPL==3 when STAR MSR is being updated. Will >> forcing SYSRET SS.DPL=3 break any OS? I think any reasonable OS would >> probably sets SS.RPL=SS.DPL=3. > > > Yes, I wondered in fact how much the AMD behavior is a bug. > > We could emulate Intel behavior on AMD by shadowing the STAR MSR; the guest > reads the intended SS.DPL and SS.RPL but the processor actually always runs > with bits 49-48 of STAR set to 3. This should ensure that CPL=SS.DPL always > even on AMD. I'm not sure if this has any worth though... When SS.DPL != CPL for a VM, the worst case without STAR emulation proposed above is the crash of the VM, which it deserves. So I think we are fine here. > > Paolo > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [Nouveau] [RFC] drm/nouveau: disable caching for VRAM BOs on ARM
On Mon, May 26, 2014 at 7:42 PM, Alexandre Courbot wrote: > On Tue, May 27, 2014 at 10:07 AM, Stéphane Marchesin > wrote: >> On Mon, May 26, 2014 at 5:02 PM, Alexandre Courbot wrote: >>> On Mon, May 26, 2014 at 6:21 PM, Lucas Stach wrote: Am Montag, den 26.05.2014, 09:45 +0300 schrieb Terje Bergström: > On 23.05.2014 17:40, Alex Courbot wrote: > > On 05/23/2014 06:59 PM, Lucas Stach wrote: > > So after checking with more knowledgeable people, it turns out this is > > the expected behavior on ARM and BAR regions should be mapped uncached > > on GK20A. All the more reasons to avoid using the BAR at all. > > This is actually specific to Tegra. > > >> You may want to make yourself aware of all the quirks required for > >> sharing memory between the GPU and CPU on an ARM host. I think there > >> are > >> far more involved than what you see now and writing an replacement for > >> TTM will not be an easy task. > >> > >> Doing away with the concept of two memory areas will not get you to a > >> single unified address space. You would have to deal with things like > >> not being able to change the caching state of pages in the systems > >> lowmem yourself. You will still have to deal with remapping pages that > >> aren't currently visible to the CPU (ok this is not an issue on Jetson > >> right now as it only has 2GB of RAM), because it's in systems highmem, > >> or even in a different LPAE area. > >> > >> You really want to be sure you are aware of all the consequences of > >> this, before considering this task. > > > > Yep, that's why I am seeking advice here. My first hope is that with a > > few tweaks we will be able to keep using TTM and the current nouveau_bo > > implementation. But unless I missed something this is not going to be > > easy. > > > > We can also use something like the patch I originally sent to make it > > work, although not with good performance, on GK20A. Not very graceful, > > but it will allow applications to run. > > > > In the long run though, we will want to achieve better performance, and > > it seems like a BO implementation targeted at UMA devices would also be > > beneficial to quite a few desktop GPUs. So as tricky as it may be I'm > > interested in gathering thoughts and why not giving it a first try with > > GK20A, even if it imposes some limitations like having buffers in lowmem > > in a first time (we can probably live with this one for a short while, > > and 64 bits will also be coming to the rescue :)) > > I don't think lowmem or LPAE is any problem, if the memory manager is > designed with that in mind. Vast majority of the buffers kernel > allocates do not need to be touched in kernel space. > > Actually I can't think of any buffers that we allocate on behalf of user > space that would need to be permanently mapped also to kernel. In case > or relocs only push buffer needs to be temporarily mapped to kernel. > > Ultimately even relocs are not necessary if we expose GPU virtual > addresses directly to user space. But that's another topic. > Nouveau already exposes constant virtual addresses to userspace and skips the pushbuf patching when the presumed offset from userspace is the same as what the kernel thinks it should be. The problem with lowmem on ARM is that you can't unmap those pages from the kernel cached mapping. So if you alloc a page, give it to userspace and userspace decides to map the page WC you just produced a conflicting mapping, which may yield undefined results on ARMv7. You may think this is not a problem as you are not touching the kernel cached mapping, but in fact it is. The CPUs prefetcher can still access this mapping. >>> >>> Why would this memory be mapped into the kernel? >> >> On ARM the kernel keeps a linear mapping of lowmem using sections >> (ARM's version of huge pages). This is always cached, and because the >> sections are not 4k, it's a pain to remove parts of it. See >> arch/arm/mm/mmu.c > > Ah, are we talking about the directly-mapped low memory region > starting at PAGE_OFFSET? Ok, it makes sense now, thanks. > > But it seems to me that such different mappings can also happen in > many other scenarios as well, don't they? How is the issue handled in > these cases? It depends. A lot of cache controllers actually implement a solution for that in hardware, in the cache controller. For example I think Tegra2 is one of those platforms. And then a lot of platforms just ignore the issue completely because it has very low probability. Stéphane -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at
linux-next: manual merge of the trivial tree with the arm-soc tree
Hi Jiri,
Today's linux-next merge of the trivial tree got a conflict in
Documentation/devicetree/bindings/arm/omap/omap.txt between commit
38b248db60e3 ("ARM: dts: Add support for DRA72x family of devices")
from the arm-soc tree and commit c98be0c96db0 ("doc: spelling error
changes") from the trivial tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc Documentation/devicetree/bindings/arm/omap/omap.txt
index 189baba40cd6,aa71962352ff..
--- a/Documentation/devicetree/bindings/arm/omap/omap.txt
+++ b/Documentation/devicetree/bindings/arm/omap/omap.txt
@@@ -126,11 -114,5 +126,11 @@@ Boards
- AM43x EPOS EVM
compatible = "ti,am43x-epos-evm", "ti,am4372", "ti,am43"
-- DRA7 EVM: Software Development Board for DRA7XX
- compatible = "ti,dra7-evm", "ti,dra7"
+- AM437x GP EVM
+ compatible = "ti,am437x-gp-evm", "ti,am4372", "ti,am43"
+
- - DRA742 EVM: Software Developement Board for DRA742
++- DRA742 EVM: Software Development Board for DRA742
+ compatible = "ti,dra7-evm", "ti,dra742", "ti,dra74", "ti,dra7"
+
+- DRA722 EVM: Software Development Board for DRA722
+ compatible = "ti,dra72-evm", "ti,dra722", "ti,dra72", "ti,dra7"
signature.asc
Description: PGP signature
[PATCH V7] serial/uart/8250: Add tunable RX interrupt trigger I/F of FIFO buffers
Add tunable RX interrupt trigger I/F of FIFO buffers. Serial devices are used as not only message communication devices but control or sending communication devices. For the latter uses, normally small data will be exchanged, so user applications want to receive data unit as soon as possible for real-time tendency. If we have a sensor which sends a 1 byte data each time and must control a device based on the sensor feedback, the RX interrupt should be triggered for each data. According to HW specification of serial UART devices, RX interrupt trigger can be changed, but the trigger is hard-coded. For example, RX interrupt trigger in 16550A can be set to 1, 4, 8, or 14 bytes for HW, but current driver sets the trigger to only 8bytes. This patch makes some devices change RX interrupt trigger from userland. - Read current setting # cat /sys/class/tty/ttyS0/rx_trig_bytes 8 - Write user setting # echo 1 > /sys/class/tty/ttyS0/rx_trig_bytes # cat /sys/class/tty/ttyS0/rx_trig_bytes 1 - 16550A and Tegra (1, 4, 8, or 14 bytes) - 16650V2 (8, 16, 24, or 28 bytes) - 16654 (8, 16, 56, or 60 bytes) - 16750 (1, 16, 32, or 56 bytes) Changed in V2: - Use _IOW for TIOCSFIFORTRIG definition - Pass the interrupt trigger value itself Changes in V3: - Change I/F from ioctl(2) to sysfs(rx_int_trig) Changes in V4: - Introduce fifo_bug flag in uart_8250_port structure This is enabled only when parity is enabled and UART_BUG_PARITY is enabled for up->bugs. If this flag is enabled, user cannot set RX trigger. - Return -EOPNOTSUPP when it does not support device at convert_fcr2val() and at convert_val2rxtrig() - Set the nearest lower RX trigger when users input a meaningless value at convert_val2rxtrig() - Check whether p->fcr is existing at serial8250_clear_and_reinit_fifos() - Set fcr = up->fcr in the begging of serial8250_do_set_termios() Changes in V5: - Support Tegra, 16650V2, 16654, and 16750 - Store default FCR value to up->fcr when the port is first created - Add rx_trig_byte[] in uart_config[] for each device and use rx_trig_byte[] in convert_fcr2val() and convert_val2rxtrig() Changes in V5.1: - Fix FCR_RX_TRIG_MAX_STATE definition Changes in V6: - Move FCR_RX_TRIG_* definition in 8250.h to include/uapi/linux/serial_reg.h, rename those to UART_FCR_R_TRIG_*, and use UART_FCR_TRIGGER_MASK to UART_FCR_R_TRIG_BITS() - Change following function names: convert_fcr2val() => fcr_get_rxtrig_bytes() convert_val2rxtrig() => bytes_to_fcr_rxtrig() - Fix typo in serial8250_do_set_termios() - Delete the verbose error message pr_info() in bytes_to_fcr_rxtrig() - Rename *rx_int_trig/rx_trig* to *rxtrig* for several functions or variables (but UI remains rx_int_trig) - Change the meaningless variable name 'val' to 'bytes' following functions: fcr_get_rxtrig_bytes(), bytes_to_fcr_rxtrig(), do_set_rxtrig(), do_serial8250_set_rxtrig(), and serial8250_set_attr_rxtrig() - Use up->fcr in order to get rxtrig_bytes instead of rx_trig_raw in fcr_get_rxtrig_bytes() - Use conf_type->rxtrig_bytes[0] instead of switch statement for support check in register_dev_spec_attr_grp() - Delete the checking whether a user changed FCR or not when minimum buffer is needed in serial8250_do_set_termios() Changes in V7: - Add Documentation - Change I/F name from rx_int_trig to rx_trig_bytes because the name rx_int_trig is hard to understand how users specify the value Signed-off-by: Yoshihiro YUNOMAE Reviewed-by: Stephen Warren Cc: Greg Kroah-Hartman Cc: Jiri Slaby Cc: Heikki Krogerus Cc: Jingoo Han Cc: Aaron Sierra Cc: linux-ser...@vger.kernel.org Cc: linux-kernel@vger.kernel.org --- Documentation/ABI/testing/sysfs-tty | 16 +++ drivers/tty/serial/8250/8250.h |2 drivers/tty/serial/8250/8250_core.c | 173 --- drivers/tty/serial/serial_core.c| 18 ++-- include/linux/serial_8250.h |2 include/linux/serial_core.h |4 + include/uapi/linux/serial_reg.h |5 + 7 files changed, 198 insertions(+), 22 deletions(-) diff --git a/Documentation/ABI/testing/sysfs-tty b/Documentation/ABI/testing/sysfs-tty index ad22fb0..9eb3c2b 100644 --- a/Documentation/ABI/testing/sysfs-tty +++ b/Documentation/ABI/testing/sysfs-tty @@ -138,3 +138,19 @@ Description: These sysfs values expose the TIOCGSERIAL interface via sysfs rather than via ioctls. + +What: /sys/class/tty/ttyS0/rx_trig_bytes +Date: May 2014 +Contact: Yoshihiro YUNOMAE +Description: +Shows current RX interrupt trigger bytes or sets the +user specified value to change it for the FIFO buffer. +Users can show or set this value regardless of opening the +serial device file or not. + +The RX trigger can be set one of four kinds of values for UART +serials. When users input a meaning less value to
Re: [PATCH V2] MIPS: change type of asid_cache to unsigned long
On 2014/5/27 12:50, Yong Zhang wrote: > BTW, I realy don't care who credits the patch and Ralf said that > he will applied the one which moves the place of udelay_val. > > Anyway, if your company pays you more money if you contribute to > the community, just take it and talk about it with Ralf ;-) > We don't do contribution for money, and I don't think you do, but crediting properly is one of the reason that our kernel community keeps prosperous for so many years, and that's one of the reason we introduced Reported-by and Tested-by tags. > Thanks, > Yong -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3.15-rc6 build / link failed fs/built-in mb_cache_entry problems
On 05/26/2014 11:17 AM, werner wrote: > building the kernel isnt successful, > > problem with _mbècache_entry_release and _get > > see below > > there are also other errors > > > The whole compiler list and config, see enclosed > > First of all, my build using your kernel config file builds -- no errors, just plenty of warnings. I am using gcc version 4.7.2. What gcc version are you using? mbcache.c uses __builtin_log2(). Maybe your gcc version does not support that builtin function. @tmac: can mbcache.c #include and use ilog2(NR_BG_LOCKS) instead of using __builtin_log2(NR_BG_LOCKS) ? (ref. commit ID 1f3e55fe02d12213f87869768aa2b0bad3ba9a7d) > > > Since appr 3.10 , even if the kernels compile and build , on meanwhile 70% > of the computers where I try to boot, the booting process crashs on different > positions. Please use return/line feed every 70-72 characters instead of assuming that all email clients will display the text correctly. They don't. > > Currently, the quality is rather bad, similar as it was during the versions > 2.6.30 ... 36 . > > So it would be good, if the programmers would check everything more careful > (im not a programmer but only an user) > > Enclosed is a compiling list, someone could see through this, and correct all > problems, such as mismatches, undefined variables, etc > > > W.Landgraf > > > > > > .. > > fs/built-in.o: In function `__mb_cache_entry_release': > mbcache.c:(.text+0xa0d5f): undefined reference to `log2' > mbcache.c:(.text+0xa0d6b): undefined reference to `__fixunsdfsi' > mbcache.c:(.text+0xa0e22): undefined reference to `log2' > mbcache.c:(.text+0xa0e34): undefined reference to `__fixunsdfsi' > mbcache.c:(.text+0xa0f4e): undefined reference to `log2' > mbcache.c:(.text+0xa0f60): undefined reference to `__fixunsdfsi' > fs/built-in.o: In function `__mb_cache_entry_find': > mbcache.c:(.text+0xa107e): undefined reference to `log2' > mbcache.c:(.text+0xa108a): undefined reference to `__fixunsdfsi' > mbcache.c:(.text+0xa115c): undefined reference to `log2' > mbcache.c:(.text+0xa116e): undefined reference to `__fixunsdfsi' > mbcache.c:(.text+0xa11dc): undefined reference to `log2' > mbcache.c:(.text+0xa11e8): undefined reference to `__fixunsdfsi' > mbcache.c:(.text+0xa126e): undefined reference to `log2' > mbcache.c:(.text+0xa1280): undefined reference to `__fixunsdfsi' > fs/built-in.o: In function `mb_cache_entry_get': > (.text+0xa3bdc): undefined reference to `log2' > fs/built-in.o: In function `mb_cache_entry_get': > (.text+0xa3bf1): undefined reference to `__fixunsdfsi' > fs/built-in.o: In function `mb_cache_entry_get': > (.text+0xa3d14): undefined reference to `log2' > fs/built-in.o: In function `mb_cache_entry_get': > (.text+0xa3d26): undefined reference to `__fixunsdfsi' > fs/built-in.o: In function `mb_cache_entry_get': > (.text+0xa3da7): undefined reference to `log2' > fs/built-in.o: In function `mb_cache_entry_get': > (.text+0xa3db3): undefined reference to `__fixunsdfsi' > fs/built-in.o: In function `mb_cache_entry_get': > (.text+0xa3e5e): undefined reference to `log2' > fs/built-in.o: In function `mb_cache_entry_get': > (.text+0xa3e70): undefined reference to `__fixunsdfsi' > make: [vmlinux] Error 1 (ignored) -- ~Randy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 7/18] qla2xxx: Use kmemdup instead of kmalloc + memcpy
Acked-by: Saurav Kashyap
>This issue was reported by coccicheck using the semantic patch
>at scripts/coccinelle/api/memdup.cocci
>
>Signed-off-by: Benoit Taine
>---
>Tested by compilation without errors.
>
> drivers/scsi/qla2xxx/qla_mbx.c |3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
>diff --git a/drivers/scsi/qla2xxx/qla_mbx.c
>b/drivers/scsi/qla2xxx/qla_mbx.c
>index 7f39e36..1c33a77 100644
>--- a/drivers/scsi/qla2xxx/qla_mbx.c
>+++ b/drivers/scsi/qla2xxx/qla_mbx.c
>@@ -1319,7 +1319,7 @@ qla2x00_get_node_name_list(scsi_qla_host_t *vha,
>void **out_data, int *out_len)
>
> left = 0;
>
>- list = kzalloc(dma_size, GFP_KERNEL);
>+ list = kmemdup(pmap, dma_size, GFP_KERNEL);
> if (!list) {
> ql_log(ql_log_warn, vha, 0x1140,
> "%s(%ld): failed to allocate node names list "
>@@ -1328,7 +1328,6 @@ qla2x00_get_node_name_list(scsi_qla_host_t *vha,
>void **out_data, int *out_len)
> goto out_free;
> }
>
>- memcpy(list, pmap, dma_size);
> restart:
> dma_free_coherent(>pdev->dev, dma_size, pmap, pmap_dma);
> }
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: pci-quirks: do not access OHCI_FMINTERVAL register on ULI hw
This access causes hang on Freescale P2020DS board (that has OHCI
provided by ULI 1533 chip).
Since preserving OHCI_FMINTERVAL was originally done only for NVIDIA
hardware and only later (in c6187597) was turned unconditional, and
c6187597 commit message again mentions only NVIDIA, I think it should be
safe to disable preserving OHCI_FMINTERVAL if device vendor is ULI.
Signed-off-by: Nikita Yushchenko
---
drivers/usb/host/pci-quirks.c |8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/host/pci-quirks.c b/drivers/usb/host/pci-quirks.c
index 00661d3..5acbd5b 100644
--- a/drivers/usb/host/pci-quirks.c
+++ b/drivers/usb/host/pci-quirks.c
@@ -571,7 +571,7 @@ static void quirk_usb_handoff_ohci(struct pci_dev *pdev)
{
void __iomem *base;
u32 control;
- u32 fminterval;
+ u32 uninitialized_var(fminterval);
int cnt;
if (!mmio_resource_enabled(pdev, 0))
@@ -619,7 +619,8 @@ static void quirk_usb_handoff_ohci(struct pci_dev *pdev)
}
/* software reset of the controller, preserving HcFmInterval */
- fminterval = readl(base + OHCI_FMINTERVAL);
+ if (pdev->vendor != PCI_VENDOR_ID_AL)
+ fminterval = readl(base + OHCI_FMINTERVAL);
writel(OHCI_HCR, base + OHCI_CMDSTATUS);
/* reset requires max 10 us delay */
@@ -628,7 +629,8 @@ static void quirk_usb_handoff_ohci(struct pci_dev *pdev)
break;
udelay(1);
}
- writel(fminterval, base + OHCI_FMINTERVAL);
+ if (pdev->vendor != PCI_VENDOR_ID_AL)
+ writel(fminterval, base + OHCI_FMINTERVAL);
/* Now the controller is safely in SUSPEND and nothing can wake it up */
iounmap(base);
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V2] MIPS: change type of asid_cache to unsigned long
On 2014/5/27 12:34, Yong Zhang wrote: > On Tue, May 27, 2014 at 12:16:30PM +0800, Li Zefan wrote: >> I'm not quite happy about what happaned here. There's a story behind >> this patch. >> >> One of our Huawei product encountered a bug, and they're using WindRiver4, >> so the kernel is 2.6.34. >> >> Because they bought your licnece, they asked for your help, but >> you were reluctant on this issue, and the problem remained there >> for about one month. >> >> At last they turned to us for help. We're the kernel department in >> Huawei, but maintaining this product kernel isn't our job. Still >> Li Bin devoted his time to analyzing this bug, and he did a great >> job. >> >> Li Bin told the product team what was wrong and was about to send >> a fix for upstream kernel. > > You have time to do that but you didn't. > Hah yeah, we do have time. we spent lots of time analyzing the bug, and we were taking our time to write good changelog. As I've pointed out that your changelog isn't informative. >> They told you our analysis for further >> confirmation, > > So you realy didn't make the patch, right? Because you are not > sure the right fix. > We're confident about our analysis and we know how to fix it. It's the product team wasn't sure about this, and they wasn't able to contact with Li Bin for confirmation at that time, so they asked you. >> and you were so reluctant to help but so quick to >> send the fix. > > We have responsed to you. > You responded to us but you did nothing to help, that's why the product team found us. >> >> Li Bin never reported this bug, but he fixed it. It's a shame that >> you took the credit from us. > > I just saw a bug report and ananysis. And I agreed and confirmed it's > a bug. > And that's our work and our credit, and I don't think you're gonna to deny 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: [PATCH V2] MIPS: change type of asid_cache to unsigned long
BTW, I realy don't care who credits the patch and Ralf said that
he will applied the one which moves the place of udelay_val.
Anyway, if your company pays you more money if you contribute to
the community, just take it and talk about it with Ralf ;-)
Thanks,
Yong
On Tue, May 27, 2014 at 12:16:30PM +0800, Li Zefan wrote:
> I'm not quite happy about what happaned here. There's a story behind
> this patch.
>
> One of our Huawei product encountered a bug, and they're using WindRiver4,
> so the kernel is 2.6.34.
>
> Because they bought your licnece, they asked for your help, but
> you were reluctant on this issue, and the problem remained there
> for about one month.
>
> At last they turned to us for help. We're the kernel department in
> Huawei, but maintaining this product kernel isn't our job. Still
> Li Bin devoted his time to analyzing this bug, and he did a great
> job.
>
> Li Bin told the product team what was wrong and was about to send
> a fix for upstream kernel. They told you our analysis for further
> confirmation, and you were so reluctant to help but so quick to
> send the fix.
>
> Li Bin never reported this bug, but he fixed it. It's a shame that
> you took the credit from us.
>
> On 2014/5/21 13:36, Yong Zhang wrote:
> > asid_cache must be unsigned long otherwise on 64bit system
> > it will become 0 if the value in get_new_mmu_context()
> > reaches 0x and in the end the assumption of
> > ASID_FIRST_VERSION is not true anymore thus leads to
> > more dangerous things.
> >
>
> We should describe what problem this bug can lead to, which
> will help people who encounter the same problem and google it.
>
> > Reported-by: libin
> > Signed-off-by: Yong Zhang
>
> Should mark the patch for stable trees. Though 2.6.34 is EOL,
> the fix should be backported to other kernels.
>
> > ---
> >
> > V2<-V1: Add the reporter.
> >
> > arch/mips/include/asm/cpu-info.h |2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/arch/mips/include/asm/cpu-info.h
> > b/arch/mips/include/asm/cpu-info.h
> > index f6299be..ebcc2ed 100644
> > --- a/arch/mips/include/asm/cpu-info.h
> > +++ b/arch/mips/include/asm/cpu-info.h
> > @@ -40,7 +40,7 @@ struct cache_desc {
> >
> > struct cpuinfo_mips {
> > unsigned intudelay_val;
> > - unsigned intasid_cache;
> > + unsigned long asid_cache;
> >
> > /*
> > * Capability and feature descriptor structure for MIPS CPU
> >
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
linux-next: build failure after merge of the regulator tree
Hi all,
After merging the regulator tree, today's linux-next build (x86_64
allmodconfig) failed like this:
drivers/built-in.o: In function `ltc3589_probe':
ltc3589.c:(.text+0xccf24): undefined reference to `devm_regmap_init_i2c'
drivers/built-in.o: In function `ltc3589_driver_init':
ltc3589.c:(.init.text+0x9ebc): undefined reference to `i2c_register_driver'
drivers/built-in.o: In function `ltc3589_driver_exit':
ltc3589.c:(.exit.text+0x2d1): undefined reference to `i2c_del_driver'
Caused by commit 3eb2c7ecb7ea ("regulator: Add LTC3589 support").
Clearly some dependencies are incorrect. Presumably the required
interfaces are in modules for this build.
I have used the regulator tree from next-20140526 for today.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
signature.asc
Description: PGP signature
Re: [PATCH V2] MIPS: change type of asid_cache to unsigned long
On Tue, May 27, 2014 at 12:16:30PM +0800, Li Zefan wrote:
> I'm not quite happy about what happaned here. There's a story behind
> this patch.
>
> One of our Huawei product encountered a bug, and they're using WindRiver4,
> so the kernel is 2.6.34.
>
> Because they bought your licnece, they asked for your help, but
> you were reluctant on this issue, and the problem remained there
> for about one month.
>
> At last they turned to us for help. We're the kernel department in
> Huawei, but maintaining this product kernel isn't our job. Still
> Li Bin devoted his time to analyzing this bug, and he did a great
> job.
>
> Li Bin told the product team what was wrong and was about to send
> a fix for upstream kernel.
You have time to do that but you didn't.
> They told you our analysis for further
> confirmation,
So you realy didn't make the patch, right? Because you are not
sure the right fix.
> and you were so reluctant to help but so quick to
> send the fix.
We have responsed to you.
>
> Li Bin never reported this bug, but he fixed it. It's a shame that
> you took the credit from us.
I just saw a bug report and ananysis. And I agreed and confirmed it's
a bug.
Thanks,
Yong
>
> On 2014/5/21 13:36, Yong Zhang wrote:
> > asid_cache must be unsigned long otherwise on 64bit system
> > it will become 0 if the value in get_new_mmu_context()
> > reaches 0x and in the end the assumption of
> > ASID_FIRST_VERSION is not true anymore thus leads to
> > more dangerous things.
> >
>
> We should describe what problem this bug can lead to, which
> will help people who encounter the same problem and google it.
>
> > Reported-by: libin
> > Signed-off-by: Yong Zhang
>
> Should mark the patch for stable trees. Though 2.6.34 is EOL,
> the fix should be backported to other kernels.
>
> > ---
> >
> > V2<-V1: Add the reporter.
> >
> > arch/mips/include/asm/cpu-info.h |2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/arch/mips/include/asm/cpu-info.h
> > b/arch/mips/include/asm/cpu-info.h
> > index f6299be..ebcc2ed 100644
> > --- a/arch/mips/include/asm/cpu-info.h
> > +++ b/arch/mips/include/asm/cpu-info.h
> > @@ -40,7 +40,7 @@ struct cache_desc {
> >
> > struct cpuinfo_mips {
> > unsigned intudelay_val;
> > - unsigned intasid_cache;
> > + unsigned long asid_cache;
> >
> > /*
> > * Capability and feature descriptor structure for MIPS CPU
> >
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/6] sched/fair.c: remove "power" from struct numa_stats
On Mon, 2014-05-26 at 23:18 -0400, Nicolas Pitre wrote: > On Tue, 27 May 2014, Mike Galbraith wrote: > > > On Mon, 2014-05-26 at 18:19 -0400, Nicolas Pitre wrote: > > > > > > @@ -1046,7 +1046,7 @@ static void update_numa_stats(struct numa_stats > > > *ns, int nid) > > > > > > ns->nr_running += rq->nr_running; > > > ns->load += weighted_cpuload(cpu); > > > - ns->power += power_of(cpu); > > > + ns->compute_capacity += power_of(cpu); > > > > power_of(cpu) as a capacity input looks odd now.. > > > > > @@ -1062,9 +1062,10 @@ static void update_numa_stats(struct numa_stats > > > *ns, int nid) > > > if (!cpus) > > > return; > > > > > > - ns->load = (ns->load * SCHED_POWER_SCALE) / ns->power; > > > - ns->capacity = DIV_ROUND_CLOSEST(ns->power, SCHED_POWER_SCALE); > > > - ns->has_capacity = (ns->nr_running < ns->capacity); > > > + ns->load = (ns->load * SCHED_POWER_SCALE) / ns->compute_capacity; > > > + ns->task_capacity = > > > + DIV_ROUND_CLOSEST(ns->compute_capacity, SCHED_POWER_SCALE); > > > > ..as do SCHED_POWER_SCALE, update_cpu_power() etc. > > The rest is renamed in a later patch. I wanted to split it into > multiple patches to keep those changes manageable. I don't see a lot of benefit in creating intermediate inconsistencies vs one bulk rename, but it does make smaller patches, so never mind. -Mike -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V2] MIPS: change type of asid_cache to unsigned long
I'm not quite happy about what happaned here. There's a story behind
this patch.
One of our Huawei product encountered a bug, and they're using WindRiver4,
so the kernel is 2.6.34.
Because they bought your licnece, they asked for your help, but
you were reluctant on this issue, and the problem remained there
for about one month.
At last they turned to us for help. We're the kernel department in
Huawei, but maintaining this product kernel isn't our job. Still
Li Bin devoted his time to analyzing this bug, and he did a great
job.
Li Bin told the product team what was wrong and was about to send
a fix for upstream kernel. They told you our analysis for further
confirmation, and you were so reluctant to help but so quick to
send the fix.
Li Bin never reported this bug, but he fixed it. It's a shame that
you took the credit from us.
On 2014/5/21 13:36, Yong Zhang wrote:
> asid_cache must be unsigned long otherwise on 64bit system
> it will become 0 if the value in get_new_mmu_context()
> reaches 0x and in the end the assumption of
> ASID_FIRST_VERSION is not true anymore thus leads to
> more dangerous things.
>
We should describe what problem this bug can lead to, which
will help people who encounter the same problem and google it.
> Reported-by: libin
> Signed-off-by: Yong Zhang
Should mark the patch for stable trees. Though 2.6.34 is EOL,
the fix should be backported to other kernels.
> ---
>
> V2<-V1: Add the reporter.
>
> arch/mips/include/asm/cpu-info.h |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/mips/include/asm/cpu-info.h
> b/arch/mips/include/asm/cpu-info.h
> index f6299be..ebcc2ed 100644
> --- a/arch/mips/include/asm/cpu-info.h
> +++ b/arch/mips/include/asm/cpu-info.h
> @@ -40,7 +40,7 @@ struct cache_desc {
>
> struct cpuinfo_mips {
> unsigned intudelay_val;
> - unsigned intasid_cache;
> + unsigned long asid_cache;
>
> /*
>* Capability and feature descriptor structure for MIPS CPU
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 4/4] mfd: intel_soc_pmic: Build files
Devices based on Intel SoC products such as Baytrail have a Power Management IC. This patch adds Intel SoC PMIC support to the build files. v2: - Add select REGMAP_I2C. v3: - Add select REGMAP_IRQ. Signed-off-by: Yang, Bin Signed-off-by: Zhu, Lejun --- drivers/mfd/Kconfig | 12 drivers/mfd/Makefile | 3 +++ 2 files changed, 15 insertions(+) diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig index 3383412..d987b71 100644 --- a/drivers/mfd/Kconfig +++ b/drivers/mfd/Kconfig @@ -241,6 +241,18 @@ config LPC_SCH LPC bridge function of the Intel SCH provides support for System Management Bus and General Purpose I/O. +config INTEL_SOC_PMIC + bool "Support for Intel Atom SoC PMIC" + depends on I2C=y + select MFD_CORE + select REGMAP_I2C + select REGMAP_IRQ + help + Select this option to enable support for the PMIC device + on some Intel SoC systems. The PMIC provides ADC, GPIO, + thermal, charger and related power management functions + on these systems. + config MFD_INTEL_MSIC bool "Intel MSIC" depends on INTEL_SCU_IPC diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile index 2851275..1a18d8b 100644 --- a/drivers/mfd/Makefile +++ b/drivers/mfd/Makefile @@ -166,3 +166,6 @@ obj-$(CONFIG_MFD_RETU) += retu-mfd.o obj-$(CONFIG_MFD_AS3711) += as3711.o obj-$(CONFIG_MFD_AS3722) += as3722.o obj-$(CONFIG_MFD_STW481X) += stw481x.o + +intel-soc-pmic-objs:= intel_soc_pmic_core.o intel_soc_pmic_crc.o intel_soc_pmic_i2c.o +obj-$(CONFIG_INTEL_SOC_PMIC) += intel-soc-pmic.o -- 1.8.3.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 3/4] mfd: intel_soc_pmic: Crystal Cove support
Crystal Cove is the PMIC in Baytrail-T platform. This patch provides
chip-specific support for Crystal Cove.
v2:
- Add regmap_config for Crystal Cove.
v3:
- Convert IRQ config to regmap_irq_chip.
Signed-off-by: Yang, Bin
Signed-off-by: Zhu, Lejun
---
drivers/mfd/intel_soc_pmic_crc.c | 175 +++
1 file changed, 175 insertions(+)
create mode 100644 drivers/mfd/intel_soc_pmic_crc.c
diff --git a/drivers/mfd/intel_soc_pmic_crc.c b/drivers/mfd/intel_soc_pmic_crc.c
new file mode 100644
index 000..341ab02
--- /dev/null
+++ b/drivers/mfd/intel_soc_pmic_crc.c
@@ -0,0 +1,175 @@
+/*
+ * intel_soc_pmic_crc.c - Device access for Crystal Cove PMIC
+ *
+ * Copyright (C) 2013, 2014 Intel Corporation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License version
+ * 2 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.
+ *
+ * Author: Yang, Bin
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include "intel_soc_pmic_core.h"
+
+#defineCHIP_NAME "Crystal Cove"
+#define CRYSTAL_COVE_MAX_REGISTER 0xC6
+
+#define CHIPID 0x00
+#define CHIPVER0x01
+#define IRQLVL10x02
+#define MIRQLVL1 0x0E
+
+enum {
+ PWRSRC_IRQ = 0,
+ THRM_IRQ,
+ BCU_IRQ,
+ ADC_IRQ,
+ CHGR_IRQ,
+ GPIO_IRQ,
+ VHDMIOCP_IRQ
+};
+
+static struct resource gpio_resources[] = {
+ {
+ .name = "GPIO",
+ .start = GPIO_IRQ,
+ .end= GPIO_IRQ,
+ .flags = IORESOURCE_IRQ,
+ },
+};
+
+static struct resource pwrsrc_resources[] = {
+ {
+ .name = "PWRSRC",
+ .start = PWRSRC_IRQ,
+ .end = PWRSRC_IRQ,
+ .flags = IORESOURCE_IRQ,
+ },
+};
+
+static struct resource adc_resources[] = {
+ {
+ .name = "ADC",
+ .start = ADC_IRQ,
+ .end = ADC_IRQ,
+ .flags = IORESOURCE_IRQ,
+ },
+};
+
+static struct resource thermal_resources[] = {
+ {
+ .name = "THERMAL",
+ .start = THRM_IRQ,
+ .end = THRM_IRQ,
+ .flags = IORESOURCE_IRQ,
+ },
+};
+
+static struct resource bcu_resources[] = {
+ {
+ .name = "BCU",
+ .start = BCU_IRQ,
+ .end = BCU_IRQ,
+ .flags = IORESOURCE_IRQ,
+ },
+};
+
+static struct mfd_cell crystal_cove_dev[] = {
+ {
+ .name = "crystal_cove_pwrsrc",
+ .id = 0,
+ .num_resources = ARRAY_SIZE(pwrsrc_resources),
+ .resources = pwrsrc_resources,
+ },
+ {
+ .name = "crystal_cove_adc",
+ .id = 0,
+ .num_resources = ARRAY_SIZE(adc_resources),
+ .resources = adc_resources,
+ },
+ {
+ .name = "crystal_cove_thermal",
+ .id = 0,
+ .num_resources = ARRAY_SIZE(thermal_resources),
+ .resources = thermal_resources,
+ },
+ {
+ .name = "crystal_cove_bcu",
+ .id = 0,
+ .num_resources = ARRAY_SIZE(bcu_resources),
+ .resources = bcu_resources,
+ },
+ {
+ .name = "crystal_cove_gpio",
+ .id = 0,
+ .num_resources = ARRAY_SIZE(gpio_resources),
+ .resources = gpio_resources,
+ },
+};
+
+static struct regmap_config crystal_cove_regmap_config = {
+ .reg_bits = 8,
+ .val_bits = 8,
+
+ .max_register = CRYSTAL_COVE_MAX_REGISTER,
+ .cache_type = REGCACHE_NONE,
+};
+
+#defineCRC_REGMAP_IRQ_VALUE(irq) { \
+ .reg_offset = 0,\
+ .mask = BIT(irq), \
+ }
+
+static const struct regmap_irq crystal_cove_irqs[] = {
+ [PWRSRC_IRQ]= CRC_REGMAP_IRQ_VALUE(PWRSRC_IRQ),
+ [THRM_IRQ] = CRC_REGMAP_IRQ_VALUE(THRM_IRQ),
+ [BCU_IRQ] = CRC_REGMAP_IRQ_VALUE(BCU_IRQ),
+ [ADC_IRQ] = CRC_REGMAP_IRQ_VALUE(ADC_IRQ),
+ [CHGR_IRQ] = CRC_REGMAP_IRQ_VALUE(CHGR_IRQ),
+ [GPIO_IRQ] = CRC_REGMAP_IRQ_VALUE(GPIO_IRQ),
+ [VHDMIOCP_IRQ] = CRC_REGMAP_IRQ_VALUE(VHDMIOCP_IRQ),
+};
+
+static struct regmap_irq_chip crystal_cove_irq_chip = {
+ .name = CHIP_NAME,
+ .irqs = crystal_cove_irqs,
+ .num_irqs = ARRAY_SIZE(crystal_cove_irqs),
+ .num_regs = 1,
+ .status_base =
[PATCH v3 2/4] mfd: intel_soc_pmic: I2C interface
The Intel SoC PMIC devices are connected to the CPU via the I2C interface. This
patch provides support of the related I2C operations.
v2:
- Use regmap instead of creating our own I2C read/write callbacks.
v3:
- Use gpiod interface instead of gpio numbers.
- Remove redundant I2C IDs.
- Use managed allocations.
Signed-off-by: Yang, Bin
Signed-off-by: Zhu, Lejun
---
drivers/mfd/intel_soc_pmic_i2c.c | 150 +++
1 file changed, 150 insertions(+)
create mode 100644 drivers/mfd/intel_soc_pmic_i2c.c
diff --git a/drivers/mfd/intel_soc_pmic_i2c.c b/drivers/mfd/intel_soc_pmic_i2c.c
new file mode 100644
index 000..3b107d7
--- /dev/null
+++ b/drivers/mfd/intel_soc_pmic_i2c.c
@@ -0,0 +1,150 @@
+/*
+ * intel_soc_pmic_i2c.c - Intel SoC PMIC MFD Driver
+ *
+ * Copyright (C) 2013, 2014 Intel Corporation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License version
+ * 2 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.
+ *
+ * Author: Yang, Bin
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include "intel_soc_pmic_core.h"
+
+static struct intel_soc_pmic *pmic_i2c;
+
+static void pmic_shutdown(struct i2c_client *client)
+{
+ disable_irq(pmic_i2c->irq);
+ return;
+}
+
+static int pmic_suspend(struct device *dev)
+{
+ disable_irq(pmic_i2c->irq);
+ return 0;
+}
+
+static int pmic_resume(struct device *dev)
+{
+ enable_irq(pmic_i2c->irq);
+ return 0;
+}
+
+static const struct dev_pm_ops pmic_pm_ops = {
+ SET_SYSTEM_SLEEP_PM_OPS(pmic_suspend, pmic_resume)
+};
+
+static int pmic_i2c_probe(struct i2c_client *i2c,
+ const struct i2c_device_id *id)
+{
+ struct gpio_desc *desc;
+ struct device *dev = >dev;
+ int irq = i2c->irq;
+
+ if (pmic_i2c != NULL) {
+ dev_err(dev, "PMIC already exists.\n");
+ return -EBUSY;
+ }
+
+ desc = devm_gpiod_get_index(dev, KBUILD_MODNAME, 0);
+ if (IS_ERR(desc)) {
+ dev_dbg(dev, "Not using GPIO as interrupt.\n");
+ } else {
+ irq = gpiod_to_irq(desc);
+ if (irq < 0) {
+ dev_warn(dev, "Can't get irq: %d\n", irq);
+ irq = i2c->irq;
+ }
+ }
+
+ pmic_i2c = devm_kzalloc(dev, sizeof(*pmic_i2c), GFP_KERNEL);
+ pmic_i2c->config = (struct intel_soc_pmic_config *)id->driver_data;
+ pmic_i2c->dev = dev;
+ pmic_i2c->regmap = devm_regmap_init_i2c(i2c,
+ pmic_i2c->config->regmap_cfg);
+ pmic_i2c->irq = irq;
+
+ return intel_pmic_add(pmic_i2c);
+}
+
+static int pmic_i2c_remove(struct i2c_client *i2c)
+{
+ int ret;
+
+ if (pmic_i2c == NULL)
+ return -ENODEV;
+
+ ret = intel_pmic_remove(pmic_i2c);
+
+ pmic_i2c = NULL;
+
+ return ret;
+}
+
+static const struct i2c_device_id pmic_i2c_id[] = {
+ { "INT33FD:00", (kernel_ulong_t)_cove_pmic},
+ { }
+};
+MODULE_DEVICE_TABLE(i2c, pmic_i2c_id);
+
+static struct acpi_device_id pmic_acpi_match[] = {
+ { "INT33FD", (kernel_ulong_t)_cove_pmic},
+ { },
+};
+MODULE_DEVICE_TABLE(acpi, pmic_acpi_match);
+
+static struct i2c_driver pmic_i2c_driver = {
+ .driver = {
+ .name = "intel_soc_pmic_i2c",
+ .owner = THIS_MODULE,
+ .pm = _pm_ops,
+ .acpi_match_table = ACPI_PTR(pmic_acpi_match),
+ },
+ .probe = pmic_i2c_probe,
+ .remove = pmic_i2c_remove,
+ .id_table = pmic_i2c_id,
+ .shutdown = pmic_shutdown,
+};
+
+static int __init pmic_i2c_init(void)
+{
+ int ret;
+
+ ret = i2c_add_driver(_i2c_driver);
+ if (ret != 0)
+ pr_err("Failed to register pmic I2C driver: %d\n", ret);
+
+ return ret;
+}
+module_init(pmic_i2c_init);
+
+static void __exit pmic_i2c_exit(void)
+{
+ i2c_del_driver(_i2c_driver);
+}
+module_exit(pmic_i2c_exit);
+
+MODULE_DESCRIPTION("I2C driver for Intel SoC PMIC");
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Yang, Bin ");
--
1.8.3.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 0/4] mfd: Intel SoC Power Management IC
Devices based on Intel SoC products such as Baytrail have a Power Management IC. In the PMIC there are subsystems for voltage regulation, A/D conversion, GPIO and PWMs. The PMIC in Baytrail-T platform is called Crystal Cove. This series contains common code for these PMICs, and device specific support for Crystal Cove. v2: - Use regmap instead of creating our own I2C read/write callbacks. - Add one missing EXPORT_SYMBOL. - Remove some duplicate code and put them into pmic_regmap_load_from_hw. v3: - Use regmap-irq and remove lots of duplicate code. - Remove 2 unused APIs. - Some other cleanup. Zhu, Lejun (4): mfd: intel_soc_pmic: Core driver mfd: intel_soc_pmic: I2C interface mfd: intel_soc_pmic: Crystal Cove support mfd: intel_soc_pmic: Build files drivers/mfd/Kconfig| 12 +++ drivers/mfd/Makefile | 3 + drivers/mfd/intel_soc_pmic_core.c | 212 + drivers/mfd/intel_soc_pmic_core.h | 44 drivers/mfd/intel_soc_pmic_crc.c | 175 ++ drivers/mfd/intel_soc_pmic_i2c.c | 150 ++ include/linux/mfd/intel_soc_pmic.h | 27 + 7 files changed, 623 insertions(+) create mode 100644 drivers/mfd/intel_soc_pmic_core.c create mode 100644 drivers/mfd/intel_soc_pmic_core.h create mode 100644 drivers/mfd/intel_soc_pmic_crc.c create mode 100644 drivers/mfd/intel_soc_pmic_i2c.c create mode 100644 include/linux/mfd/intel_soc_pmic.h -- 1.8.3.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 1/4] mfd: intel_soc_pmic: Core driver
This patch provides the common code for the intel_soc_pmic MFD driver, such as
read/write register and set up IRQ.
v2:
- Use regmap instead of our own callbacks for read/write.
- Add one missing EXPORT_SYMBOL.
- Remove some duplicate code and put them into pmic_regmap_load_from_hw.
v3:
- Use regmap-irq. Remove our own pmic_regmap_* and IRQ handling code.
- Remove intel_soc_pmic_dev() because gpio driver no longer uses it.
- Remove intel_soc_pmic_set_pdata() because currently it's not used.
- Use EXPORT_SYMBOL_GPL for exposed APIs.
Signed-off-by: Yang, Bin
Signed-off-by: Zhu, Lejun
---
drivers/mfd/intel_soc_pmic_core.c | 212 +
drivers/mfd/intel_soc_pmic_core.h | 44
include/linux/mfd/intel_soc_pmic.h | 27 +
3 files changed, 283 insertions(+)
create mode 100644 drivers/mfd/intel_soc_pmic_core.c
create mode 100644 drivers/mfd/intel_soc_pmic_core.h
create mode 100644 include/linux/mfd/intel_soc_pmic.h
diff --git a/drivers/mfd/intel_soc_pmic_core.c
b/drivers/mfd/intel_soc_pmic_core.c
new file mode 100644
index 000..4f95a4a
--- /dev/null
+++ b/drivers/mfd/intel_soc_pmic_core.c
@@ -0,0 +1,212 @@
+/*
+ * intel_soc_pmic_core.c - Intel SoC PMIC Core Functions
+ *
+ * Copyright (C) 2013, 2014 Intel Corporation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License version
+ * 2 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.
+ *
+ * Author: Yang, Bin
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include "intel_soc_pmic_core.h"
+
+static DEFINE_MUTEX(pmic_lock);/* protect pmic */
+static struct intel_soc_pmic *pmic;
+
+/*
+ * Read from a PMIC register
+ */
+int intel_soc_pmic_readb(int reg)
+{
+ int ret;
+ unsigned int val;
+
+ mutex_lock(_lock);
+
+ if (!pmic) {
+ ret = -EIO;
+ } else {
+ ret = regmap_read(pmic->regmap, reg, );
+ if (!ret)
+ ret = val;
+ }
+
+ mutex_unlock(_lock);
+
+ return ret;
+}
+EXPORT_SYMBOL_GPL(intel_soc_pmic_readb);
+
+/*
+ * Write to a PMIC register
+ */
+int intel_soc_pmic_writeb(int reg, u8 val)
+{
+ int ret;
+
+ mutex_lock(_lock);
+
+ if (!pmic)
+ ret = -EIO;
+ else
+ ret = regmap_write(pmic->regmap, reg, val);
+
+ mutex_unlock(_lock);
+
+ return ret;
+}
+EXPORT_SYMBOL_GPL(intel_soc_pmic_writeb);
+
+/*
+ * Set 1 bit in a PMIC register
+ */
+int intel_soc_pmic_setb(int reg, u8 mask)
+{
+ int ret;
+
+ mutex_lock(_lock);
+
+ if (!pmic)
+ ret = -EIO;
+ else
+ ret = regmap_update_bits(pmic->regmap, reg, mask, mask);
+
+ mutex_unlock(_lock);
+
+ return ret;
+}
+EXPORT_SYMBOL_GPL(intel_soc_pmic_setb);
+
+/*
+ * Clear 1 bit in a PMIC register
+ */
+int intel_soc_pmic_clearb(int reg, u8 mask)
+{
+ int ret;
+
+ mutex_lock(_lock);
+
+ if (!pmic)
+ ret = -EIO;
+ else
+ ret = regmap_update_bits(pmic->regmap, reg, mask, 0);
+
+ mutex_unlock(_lock);
+
+ return ret;
+}
+EXPORT_SYMBOL_GPL(intel_soc_pmic_clearb);
+
+/*
+* Set and clear multiple bits of a PMIC register
+*/
+int intel_soc_pmic_update(int reg, u8 val, u8 mask)
+{
+ int ret;
+
+ mutex_lock(_lock);
+
+ if (!pmic)
+ ret = -EIO;
+ else
+ ret = regmap_update_bits(pmic->regmap, reg, mask, val);
+
+ mutex_unlock(_lock);
+
+ return ret;
+}
+EXPORT_SYMBOL_GPL(intel_soc_pmic_update);
+
+int intel_pmic_add(struct intel_soc_pmic *chip)
+{
+ int ret;
+ struct intel_soc_pmic_config *cfg = chip->config;
+
+ mutex_lock(_lock);
+
+ if (pmic != NULL) {
+ mutex_unlock(_lock);
+ return -EBUSY;
+ }
+
+ pmic = chip;
+
+ mutex_unlock(_lock);
+
+ if (cfg->init) {
+ ret = cfg->init();
+ if (ret != 0)
+ goto err;
+ }
+
+ ret = regmap_add_irq_chip(chip->regmap, chip->irq,
+ cfg->irq_flags | IRQF_ONESHOT,
+ 0, cfg->irq_chip,
+ >irq_chip_data);
+ if (ret != 0)
+ goto err;
+
+ ret = enable_irq_wake(chip->irq);
+ if (ret != 0)
+ dev_warn(chip->dev, "Can't enable IRQ as wake source: %d\n",
+ret);
+
+ ret = mfd_add_devices(chip->dev, -1,
Re: [jet.c...@intel.com: [bio] kernel BUG at drivers/block/virtio_blk.c:166!]
On Tue, May 27, 2014 at 3:43 AM, Maurizio Lombardi wrote:
> Hi Jens,
>
> looks like that commit 3979ef4dcf3d1de55a560a3a4016c30a835df44d
> ("bio-modify-__bio_add_page-to-accept-pages-that-dont-start-a-new-segment-v3")
> introduces a regression, as reported by Jet Chan.
>
> Do you have any idea about the possible problem with this patch?
>
> it is the one that performs a recount of the segments in case of failure in
> __bio_add_page()
>
> http://www.spinics.net/lists/mm-commits/msg103684.html
>
> I would not be surprised if the bug was introduced by fceb38f36f, because it
> contained a mystake that commit 3979ef4dcf supposedly fixed.
> But learning that commit 3979ef4dcf is introducing a regression leaves
> me quite puzzled.
>From code of __blk_recalc_rq_segments(), looks it
won't check if recounted physical segment number is
bigger than queue_max_segments(), so wondering if
blk_recount_segments() can always decrease
physical segment number.
Thanks,
--
Ming Lei
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: fs/dcache.c - BUG: soft lockup - CPU#5 stuck for 22s! [systemd-udevd:1667]
On Tue, May 27, 2014 at 04:14:15AM +0100, Al Viro wrote:
> As the matter of fact, let's try this instead - retry the same sucker
> immediately in case if trylocks fail. Comments?
Better yet, let's take "move back to shrink list" into dentry_kill()
itself. Then we get consistent locking rules for dentry_kill() and
instead of unlock_on_failure we simply pass it NULL or the shrink
list to put the sucker back. Mika, could you test this one and see
if it fixes that livelock? The difference in behaviour is that in
case of trylock failure we hit that sucker again without letting
it ride all the way around the list, same as we do for other dentry_kill()
callers.
Signed-off-by: Al Viro
---
diff --git a/fs/dcache.c b/fs/dcache.c
index 42ae01e..77c95e5 100644
--- a/fs/dcache.c
+++ b/fs/dcache.c
@@ -448,7 +448,7 @@ EXPORT_SYMBOL(d_drop);
* Returns dentry requiring refcount drop, or NULL if we're done.
*/
static struct dentry *
-dentry_kill(struct dentry *dentry, int unlock_on_failure)
+dentry_kill(struct dentry *dentry, struct list_head *shrink_list)
__releases(dentry->d_lock)
{
struct inode *inode;
@@ -464,10 +464,10 @@ dentry_kill(struct dentry *dentry, int unlock_on_failure)
inode = dentry->d_inode;
if (inode && !spin_trylock(>i_lock)) {
relock:
- if (unlock_on_failure) {
- spin_unlock(>d_lock);
- cpu_relax();
- }
+ if (shrink_list)
+ d_shrink_add(dentry, shrink_list);
+ spin_unlock(>d_lock);
+ cpu_relax();
return dentry; /* try again with same dentry */
}
if (!IS_ROOT(dentry))
@@ -579,7 +579,7 @@ repeat:
return;
kill_it:
- dentry = dentry_kill(dentry, 1);
+ dentry = dentry_kill(dentry, NULL);
if (dentry)
goto repeat;
}
@@ -798,6 +798,7 @@ static void shrink_dentry_list(struct list_head *list)
while (!list_empty(list)) {
dentry = list_entry(list->prev, struct dentry, d_lru);
+again:
spin_lock(>d_lock);
/*
* The dispose list is isolated and dentries are not accounted
@@ -815,23 +816,16 @@ static void shrink_dentry_list(struct list_head *list)
continue;
}
- parent = dentry_kill(dentry, 0);
+ parent = dentry_kill(dentry, list);
/*
* If dentry_kill returns NULL, we have nothing more to do.
*/
if (!parent)
continue;
- if (unlikely(parent == dentry)) {
- /*
-* trylocks have failed and d_lock has been held the
-* whole time, so it could not have been added to any
-* other lists. Just add it back to the shrink list.
-*/
- d_shrink_add(dentry, list);
- spin_unlock(>d_lock);
- continue;
- }
+/* if trylocks have failed; just do it again */
+ if (unlikely(parent == dentry))
+ goto again;
/*
* We need to prune ancestors too. This is necessary to prevent
* quadratic behavior of shrink_dcache_parent(), but is also
@@ -840,7 +834,7 @@ static void shrink_dentry_list(struct list_head *list)
*/
dentry = parent;
while (dentry && !lockref_put_or_lock(>d_lockref))
- dentry = dentry_kill(dentry, 1);
+ dentry = dentry_kill(dentry, NULL);
}
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 12/12] [include/linux] Remove strict_strto definitions
On Mon, 2014-05-26 at 23:17 +0100, Daniel Walter wrote: > From: Daniel Walter > Subject: [PATCH 12/12] [include/linux] remove strict_strto* definitions > > Remove obsolete and unused strict_strto* functions > > Signed-off-by: Daniel Walter Acked-by: Steven Rostedt -- Steve > --- > include/linux/kernel.h | 4 > 1 file changed, 4 deletions(-) > > diff --git a/include/linux/kernel.h b/include/linux/kernel.h > index 4c52907..a39043c 100644 > --- a/include/linux/kernel.h > +++ b/include/linux/kernel.h > @@ -376,10 +376,6 @@ extern unsigned long simple_strtoul(const char *,char > **,unsigned int); > extern long simple_strtol(const char *,char **,unsigned int); > extern unsigned long long simple_strtoull(const char *,char **,unsigned int); > extern long long simple_strtoll(const char *,char **,unsigned int); > -#define strict_strtoul kstrtoul > -#define strict_strtolkstrtol > -#define strict_strtoull kstrtoull > -#define strict_strtoll kstrtoll > > extern int num_to_str(char *buf, int size, unsigned long long num); > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/5] regulator: tps65917: Add Regulator driver for tps65917 PMIC
Hi Mark, On Monday 26 May 2014 08:30 PM, Mark Brown wrote: On Mon, May 26, 2014 at 03:26:37PM +0530, Keerthy wrote: This patch adds support for TPS65917 PMIC regulators. The regulators set consists of 5 SMPSs and 5 LDOs. The output voltages are configurable and are meant to supply power to the main processor and other components. This appears to look *very* like the Palmas driver, should it not be sharing code with that? If it were just data tables it'd be less of a concern but there's quite a bit of actual code here. Yes it is. The difference is in the entire register space of the regulators between the two. There are other differences in how the ramp delay is configured and SMPS ordering. The difference is also a bit in the programming sequence. I agree that largely it is Palmas based. I did not want to add more checks in the probe of the palmas driver. Hence came up with a new one. Coming to sharing the code, can we have 2 drivers which share the common functions with separate data and specific functions? I just simply do not want to add anything more to the palmas driver probe function. Kind Regards, Keerthy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] IIO: Added iio magn_north ABI documentation
Added documentation for HID magnometer true/magnetic north sensor. --- Documentation/ABI/testing/sysfs-bus-iio | 76 + 1 file changed, 76 insertions(+) diff --git a/Documentation/ABI/testing/sysfs-bus-iio b/Documentation/ABI/testing/sysfs-bus-iio index 6e02c50..3305fe8 100644 --- a/Documentation/ABI/testing/sysfs-bus-iio +++ b/Documentation/ABI/testing/sysfs-bus-iio @@ -165,6 +165,10 @@ Description: What: /sys/bus/iio/devices/iio:deviceX/in_magn_x_raw What: /sys/bus/iio/devices/iio:deviceX/in_magn_y_raw What: /sys/bus/iio/devices/iio:deviceX/in_magn_z_raw +What: /sys/bus/iio/devices/iio:deviceX/in_magn_north_magnetic_raw +What: /sys/bus/iio/devices/iio:deviceX/in_magn_north_true_raw +What: /sys/bus/iio/devices/iio:deviceX/in_magn_north_magnetic_tilt_compensated_raw +What: /sys/bus/iio/devices/iio:deviceX/in_magn_north_true_tilt_compensated_raw KernelVersion: 2.6.35 Contact: linux-...@vger.kernel.org Description: @@ -249,6 +253,10 @@ What: /sys/bus/iio/devices/iio:deviceX/in_magn_scale What: /sys/bus/iio/devices/iio:deviceX/in_magn_x_scale What: /sys/bus/iio/devices/iio:deviceX/in_magn_y_scale What: /sys/bus/iio/devices/iio:deviceX/in_magn_z_scale +What: /sys/bus/iio/devices/iio:deviceX/in_magn_north_magnetic_scale +What: /sys/bus/iio/devices/iio:deviceX/in_magn_north_true_scale +What: /sys/bus/iio/devices/iio:deviceX/in_magn_north_magnetic_tilt_compensated_scale +What: /sys/bus/iio/devices/iio:deviceX/in_magn_north_true_tilt_compensated_scale What: /sys/bus/iio/devices/iio:deviceX/in_pressureY_scale What: /sys/bus/iio/devices/iio:deviceX/in_pressure_scale KernelVersion: 2.6.35 @@ -436,6 +444,14 @@ What: /sys/.../iio:deviceX/events/in_magn_y_thresh_rising_en What: /sys/.../iio:deviceX/events/in_magn_y_thresh_falling_en What: /sys/.../iio:deviceX/events/in_magn_z_thresh_rising_en What: /sys/.../iio:deviceX/events/in_magn_z_thresh_falling_en +What: /sys/.../iio:deviceX/events/in_magn_north_magnetic_thresh_rising_en +What: /sys/.../iio:deviceX/events/in_magn_north_magnetic_thresh_falling_en +What: /sys/.../iio:deviceX/events/in_magn_north_true_thresh_rising_en +What: /sys/.../iio:deviceX/events/in_magn_north_true_thresh_falling_en +What: /sys/.../iio:deviceX/events/in_magn_north_magnetic_tilt_compensated_thresh_rising_en +What: /sys/.../iio:deviceX/events/in_magn_north_magnetic_tilt_compensated_thresh_falling_en +What: /sys/.../iio:deviceX/events/in_magn_north_true_tilt_compensated_thresh_rising_en +What: /sys/.../iio:deviceX/events/in_magn_north_true_tilt_compensated_thresh_falling_en What: /sys/.../iio:deviceX/events/in_voltageY_supply_thresh_rising_en What: /sys/.../iio:deviceX/events/in_voltageY_supply_thresh_falling_en What: /sys/.../iio:deviceX/events/in_voltageY_thresh_rising_en @@ -481,6 +497,14 @@ What: /sys/.../iio:deviceX/events/in_magn_y_roc_rising_en What: /sys/.../iio:deviceX/events/in_magn_y_roc_falling_en What: /sys/.../iio:deviceX/events/in_magn_z_roc_rising_en What: /sys/.../iio:deviceX/events/in_magn_z_roc_falling_en +What: /sys/.../iio:deviceX/events/in_magn_north_magnetic_roc_rising_en +What: /sys/.../iio:deviceX/events/in_magn_north_magnetic_roc_falling_en +What: /sys/.../iio:deviceX/events/in_magn_north_true_roc_rising_en +What: /sys/.../iio:deviceX/events/in_magn_north_true_roc_falling_en +What: /sys/.../iio:deviceX/events/in_magn_north_magnetic_tilt_compensated_roc_rising_en +What: /sys/.../iio:deviceX/events/in_magn_north_magnetic_tilt_compensated_roc_falling_en +What: /sys/.../iio:deviceX/events/in_magn_north_true_tilt_compensated_roc_rising_en +What: /sys/.../iio:deviceX/events/in_magn_north_true_tilt_compensated_roc_falling_en What: /sys/.../iio:deviceX/events/in_voltageY_supply_roc_rising_en What: /sys/.../iio:deviceX/events/in_voltageY_supply_roc_falling_en What: /sys/.../iio:deviceX/events/in_voltageY_roc_rising_en @@ -527,6 +551,14 @@ What: /sys/.../events/in_magn_y_raw_thresh_rising_value What: /sys/.../events/in_magn_y_raw_thresh_falling_value What: /sys/.../events/in_magn_z_raw_thresh_rising_value What: /sys/.../events/in_magn_z_raw_thresh_falling_value +What: /sys/.../events/in_magn_north_magnetic_raw_thresh_rising_value +What: /sys/.../events/in_magn_north_magnetic_raw_thresh_falling_value +What: /sys/.../events/in_magn_north_true_raw_thresh_rising_value +What: /sys/.../events/in_magn_north_true_raw_thresh_falling_value +What:
[PATCH] IIO: Support for True/Magnetic north
Hey Jonathan and Srinivas, I have added in the needed magn_north iio sysfs attributes to the documentation. I hope I did everything correct. I noticed that the line length was very long as compensated is a fairly long word. I'm thinking I could shorten some of the sysfs paths or shorten the name. For updating the hid-sensor-magn-3d do you have any tips on this? I'm thinking I'll need a dynamic iio_chan array that is passed to iio_register function. It would need to be dynamic in the sense it would only add channels if it found x, y, z, or one of the north attributes. I'll start working on this soon. Thank You, Reyad Attiyat Reyad Attiyat (1): IIO: Added iio magn_north ABI documentation Documentation/ABI/testing/sysfs-bus-iio | 76 + 1 file changed, 76 insertions(+) -- 1.9.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/6] sched/fair.c: remove "power" from struct numa_stats
On Tue, 27 May 2014, Mike Galbraith wrote: > On Mon, 2014-05-26 at 18:19 -0400, Nicolas Pitre wrote: > > > > @@ -1046,7 +1046,7 @@ static void update_numa_stats(struct numa_stats *ns, > > int nid) > > > > ns->nr_running += rq->nr_running; > > ns->load += weighted_cpuload(cpu); > > - ns->power += power_of(cpu); > > + ns->compute_capacity += power_of(cpu); > > power_of(cpu) as a capacity input looks odd now.. > > > @@ -1062,9 +1062,10 @@ static void update_numa_stats(struct numa_stats *ns, > > int nid) > > if (!cpus) > > return; > > > > - ns->load = (ns->load * SCHED_POWER_SCALE) / ns->power; > > - ns->capacity = DIV_ROUND_CLOSEST(ns->power, SCHED_POWER_SCALE); > > - ns->has_capacity = (ns->nr_running < ns->capacity); > > + ns->load = (ns->load * SCHED_POWER_SCALE) / ns->compute_capacity; > > + ns->task_capacity = > > + DIV_ROUND_CLOSEST(ns->compute_capacity, SCHED_POWER_SCALE); > > ..as do SCHED_POWER_SCALE, update_cpu_power() etc. The rest is renamed in a later patch. I wanted to split it into multiple patches to keep those changes manageable. Nicolas -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] cpufreq: governor: Be friendly towards latency-sensitive bursty workloads
On 05/27/2014 04:57 AM, Rafael J. Wysocki wrote: > Hi Srivatsa, > > On Tuesday, May 27, 2014 02:23:38 AM Srivatsa S. Bhat wrote: >> Cpufreq governors like the ondemand governor calculate the load on the CPU >> periodically by employing deferrable timers. A deferrable timer won't fire >> if the CPU is completely idle (and there are no other timers to be run), in >> order to avoid unnecessary wakeups and thus save CPU power. >> >> However, the load calculation logic is agnostic to all this, and this can >> lead to the problem described below. > > This is subtle enough that I need some more time to chew on it, but since the > merge window is coming, I'm not sure when that's going to happen honestly. > Sure, I completely understand. Please take your time, no hurry! Thank you very much! Regards, Srivatsa S. Bhat -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: fs/dcache.c - BUG: soft lockup - CPU#5 stuck for 22s! [systemd-udevd:1667]
On Tue, May 27, 2014 at 02:40:54AM +0100, Al Viro wrote:
> It looks plausible, but I doubt that serializing check_submounts_and_drop()
> will suffice - shrink_dcache_parent() is just as unpleasant and it *is*
> triggered in the same situations. Moreover, the lack of loop in memory
> shrinkers doesn't help - we might get shrink_dentry_list() from one of
> those and loops that keep calling d_walk() from check_submounts_and_drop()
> or shrink_dcache_parent()...
>
> > Anyway, I'd like Mika to test the stupid "let's serialize the dentry
> > shrinking in check_submounts_and_drop()" to see if his problem goes
> > away. I agree that it's not the _proper_ fix, but we're damn late in
> > the rc series..
>
> That we are... FWIW, if the nastiness matches the description above,
> the right place to do something probably would be when those two
> suckers get positive return value from d_walk() along with an empty
> shrink list. I wonder if we should do down_read() in shrink_dentry_list()
> and down_write();up_write() in that case in shrink_dcache_parent() and
> check_submounts_and_drop(). How about the following?
As the matter of fact, let's try this instead - retry the same sucker
immediately in case if trylocks fail. Comments?
diff --git a/fs/dcache.c b/fs/dcache.c
index 42ae01e..d58d4cc 100644
--- a/fs/dcache.c
+++ b/fs/dcache.c
@@ -798,6 +798,7 @@ static void shrink_dentry_list(struct list_head *list)
while (!list_empty(list)) {
dentry = list_entry(list->prev, struct dentry, d_lru);
+again:
spin_lock(>d_lock);
/*
* The dispose list is isolated and dentries are not accounted
@@ -830,7 +831,8 @@ static void shrink_dentry_list(struct list_head *list)
*/
d_shrink_add(dentry, list);
spin_unlock(>d_lock);
- continue;
+ cpu_relax();
+ goto again;
}
/*
* We need to prune ancestors too. This is necessary to prevent
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 09/27] mtd: nand: pxa3xx: show device structure in sysfs
Tue, 27 May 2014 00:12:34 +0200 от Alexander Holler : > Fix a common error in nand-drivers which do not set up a parent device for > the mtd-device by using a new inline function. > > Signed-off-by: Alexander Holler > --- > drivers/mtd/nand/pxa3xx_nand.c | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > diff --git a/drivers/mtd/nand/pxa3xx_nand.c b/drivers/mtd/nand/pxa3xx_nand.c > index 7588fe2..7f62e7c 100644 > --- a/drivers/mtd/nand/pxa3xx_nand.c > +++ b/drivers/mtd/nand/pxa3xx_nand.c > @@ -1584,8 +1584,7 @@ static int alloc_nand_resource(struct platform_device > *pdev) > host->mtd = mtd; > host->cs = cs; > host->info_data = info; > - mtd->priv = host; > - mtd->owner = THIS_MODULE; > + mtd_setup_common_members(mtd, host, pdev); > > chip->ecc.read_page = pxa3xx_nand_read_page_hwecc; > chip->ecc.write_page= pxa3xx_nand_write_page_hwecc; > -- Should we add "driver.owner = THIS_MODULE" field for struct platform_driver in this case? ---
Re: [PATCH v2 1/6] sched/fair.c: remove "power" from struct numa_stats
On Mon, 2014-05-26 at 18:19 -0400, Nicolas Pitre wrote: > > @@ -1046,7 +1046,7 @@ static void update_numa_stats(struct numa_stats *ns, > int nid) > > ns->nr_running += rq->nr_running; > ns->load += weighted_cpuload(cpu); > - ns->power += power_of(cpu); > + ns->compute_capacity += power_of(cpu); power_of(cpu) as a capacity input looks odd now.. > @@ -1062,9 +1062,10 @@ static void update_numa_stats(struct numa_stats *ns, > int nid) > if (!cpus) > return; > > - ns->load = (ns->load * SCHED_POWER_SCALE) / ns->power; > - ns->capacity = DIV_ROUND_CLOSEST(ns->power, SCHED_POWER_SCALE); > - ns->has_capacity = (ns->nr_running < ns->capacity); > + ns->load = (ns->load * SCHED_POWER_SCALE) / ns->compute_capacity; > + ns->task_capacity = > + DIV_ROUND_CLOSEST(ns->compute_capacity, SCHED_POWER_SCALE); ..as do SCHED_POWER_SCALE, update_cpu_power() etc. -Mike -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [RFT][PATCH] regulator: pfuze100: Support enable/disable for fixed regulator
Tested-by: Robin Gong
Acked-by: Robin Gong
-Original Message-
From: Axel Lin [mailto:axel@ingics.com]
Sent: Monday, May 26, 2014 5:56 PM
To: Mark Brown
Cc: Gong Yibin-B38343; Estevam Fabio-R49496; Liam Girdwood;
linux-kernel@vger.kernel.org
Subject: [RFT][PATCH] regulator: pfuze100: Support enable/disable for fixed
regulator
Current code has .enable_reg and .enable_mask settings, but the implementation
for corresponding callbacks are missing. Fix it.
Signed-off-by: Axel Lin
---
Hi Robin,
Can you review and test this patch?
Thanks,
Axel
drivers/regulator/pfuze100-regulator.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/regulator/pfuze100-regulator.c
b/drivers/regulator/pfuze100-regulator.c
index 67e678c..b6b4529 100644
--- a/drivers/regulator/pfuze100-regulator.c
+++ b/drivers/regulator/pfuze100-regulator.c
@@ -125,6 +125,9 @@ static struct regulator_ops pfuze100_ldo_regulator_ops = {
};
static struct regulator_ops pfuze100_fixed_regulator_ops = {
+ .enable = regulator_enable_regmap,
+ .disable = regulator_disable_regmap,
+ .is_enabled = regulator_is_enabled_regmap,
.list_voltage = regulator_list_voltage_linear, };
--
1.8.3.2
Re: [PATCH] export efi.flags to sysfs
On 05/26/14 at 04:39pm, Dave Young wrote:
>
> For efi=old_map and any old_map quirks like SGI UV in current
> tree kexec/kdump will fail because it depends on the new 1:1 mapping.
>
> Thus export the mapping method to sysfs so kexec tools can switch
> to original way to boot.
>
> Since we have efi.flags for all efi facilities so let's just export the
> efi.flags itself, it maybe useful for other arches and use cases.
Rethink about this issue, export flags will expose the efi facility
macros to userspace, Matt, what's your opinion? It might be better to export
a file 'old_map' only which is '0|1'
>
> Signed-off-by: Dave Young
> ---
> drivers/firmware/efi/efi.c |3 +++
> 1 file changed, 3 insertions(+)
>
> Index: linux-2.6/drivers/firmware/efi/efi.c
> ===
> --- linux-2.6.orig/drivers/firmware/efi/efi.c
> +++ linux-2.6/drivers/firmware/efi/efi.c
> @@ -86,16 +86,19 @@ static ssize_t name##_show(struct kobjec
> EFI_ATTR_SHOW(fw_vendor);
> EFI_ATTR_SHOW(runtime);
> EFI_ATTR_SHOW(config_table);
> +EFI_ATTR_SHOW(flags);
>
> static struct kobj_attribute efi_attr_fw_vendor = __ATTR_RO(fw_vendor);
> static struct kobj_attribute efi_attr_runtime = __ATTR_RO(runtime);
> static struct kobj_attribute efi_attr_config_table = __ATTR_RO(config_table);
> +static struct kobj_attribute efi_attr_flags = __ATTR_RO(flags);
>
> static struct attribute *efi_subsys_attrs[] = {
> _attr_systab.attr,
> _attr_fw_vendor.attr,
> _attr_runtime.attr,
> _attr_config_table.attr,
> + _attr_flags.attr,
> NULL,
> };
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [lxc-devel] [RFC PATCH 11/11] loop: Allow priveleged operations for root in the namespace which owns a device
On Tue, 2014-05-27 at 03:36 +0200, Serge E. Hallyn wrote: > Quoting Michael H. Warfield (m...@wittsend.com): > > On Mon, 2014-05-26 at 11:16 +0200, Seth Forshee wrote: > > > On Fri, May 23, 2014 at 08:48:25AM +0300, Marian Marinov wrote: > > > > -BEGIN PGP SIGNED MESSAGE- > > > > Hash: SHA1 > > > > > > > > One question about this patch. > > > > > > > > Why don't you use the devices cgroup check if the root user in that > > > > namespace is allowed to use this device? > > > > > > > > This way you can be sure that the root in that namespace can not access > > > > devices to which the host system did not gave > > > > him access to. > > > > > That might be possible, but I don't want to require something on the > > > host to whitelist the device for the container. Then loop would need to > > > automatically add the device to devices.allow, which doesn't seem > > > desirable to me. But I'm not entirely opposed to the idea if others > > > think this is a better way to go. > > > > I don't see any safe way to avoid it. The host has to be in control of > > what devices can and can not be accessed by the container. > Disagree. loop%d is meaningless until it is attached to a file. So > whether a container can use loop2 vs loop9 is meaningless. The point > of Seth's loopfs as I understood it is that the container simply gets a > unique (not visible to host or any other containers) set of loop devices > which it can attach to files which it owns. So long as the host can't > see the container's loop devices (i.e. so it unwittently mounts it when > looking for a particular UUID for /var), it won't get fooled by them. > So in this case *if* we can do it, a purely namespaced approach - meaning > that we restrict visibility of a particular loopdev to one container - is > perfect. And in that "*if" is a cloud that says "then a miracle occurs" and that miracle needs a lot more detail. How that translates into what is and is not visible and what can be mimiced in a container becomes important (to say nothing of notifying its udev). I think this loopfs thing is the answer for the loop device case, we just need to clear up those details and exorcise the devils we find in them. The loop devices are unique while they strangely seem to work with minimal leakage already (all meta data at this time). Seth remarked that, maybe, he's not paranoid enough. You know that I'm a well trained professional paranoid and I accept if people think I'm overly paranoid (is that even possible?). Even paranoids have enemies and just because you're paranoid it doesn't mean they're not out to get you. While I admit that total isolation is virtually (excuse the pun) impossible that doesn't mean I don't strive to maximize the isolation and analyze the possibilities and consequences of compromise. As I stated, "I don't see any way to avoid it". I would love to be proven wrong. It would permit my life to be so much more easy. But how can we allow this without the host in control of it and directing things to the containers? A container may request something and the host can grant it but the container should not be capable of demanding a device over and above the control of the host. How do we define the rules that say what a container can do and what it cannot do without it involving knowledge in the host (whitelisting as Seth call's it) of what is and is not allowed in the container? We already have the problem that the container devices.allow and devices.deny are major and minor based, which we know is fundamentally flawed in a udev environment. We specify major:minor in the configuration files as if they are cast in cement (which they are in all common cases) but they are not in the general case. Greg K-H hammers on this frequently. The loop devices are unique and deserve a unique solution, I'll agree. But I'm also comfortable that the host should have rules and procedures to whitelist hard devices and loop devices and manage their transfer and/or sharing into the containers. Regards, Mike -- Michael H. Warfield (AI4NB) | (770) 978-7061 | m...@wittsend.com /\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0x674627FF| possible worlds. A pessimist is sure of it! signature.asc Description: This is a digitally signed message part
Re: [Nouveau] [RFC] drm/nouveau: disable caching for VRAM BOs on ARM
On Tue, May 27, 2014 at 10:07 AM, Stéphane Marchesin wrote: > On Mon, May 26, 2014 at 5:02 PM, Alexandre Courbot wrote: >> On Mon, May 26, 2014 at 6:21 PM, Lucas Stach wrote: >>> Am Montag, den 26.05.2014, 09:45 +0300 schrieb Terje Bergström: On 23.05.2014 17:40, Alex Courbot wrote: > On 05/23/2014 06:59 PM, Lucas Stach wrote: > So after checking with more knowledgeable people, it turns out this is > the expected behavior on ARM and BAR regions should be mapped uncached > on GK20A. All the more reasons to avoid using the BAR at all. This is actually specific to Tegra. >> You may want to make yourself aware of all the quirks required for >> sharing memory between the GPU and CPU on an ARM host. I think there are >> far more involved than what you see now and writing an replacement for >> TTM will not be an easy task. >> >> Doing away with the concept of two memory areas will not get you to a >> single unified address space. You would have to deal with things like >> not being able to change the caching state of pages in the systems >> lowmem yourself. You will still have to deal with remapping pages that >> aren't currently visible to the CPU (ok this is not an issue on Jetson >> right now as it only has 2GB of RAM), because it's in systems highmem, >> or even in a different LPAE area. >> >> You really want to be sure you are aware of all the consequences of >> this, before considering this task. > > Yep, that's why I am seeking advice here. My first hope is that with a > few tweaks we will be able to keep using TTM and the current nouveau_bo > implementation. But unless I missed something this is not going to be > easy. > > We can also use something like the patch I originally sent to make it > work, although not with good performance, on GK20A. Not very graceful, > but it will allow applications to run. > > In the long run though, we will want to achieve better performance, and > it seems like a BO implementation targeted at UMA devices would also be > beneficial to quite a few desktop GPUs. So as tricky as it may be I'm > interested in gathering thoughts and why not giving it a first try with > GK20A, even if it imposes some limitations like having buffers in lowmem > in a first time (we can probably live with this one for a short while, > and 64 bits will also be coming to the rescue :)) I don't think lowmem or LPAE is any problem, if the memory manager is designed with that in mind. Vast majority of the buffers kernel allocates do not need to be touched in kernel space. Actually I can't think of any buffers that we allocate on behalf of user space that would need to be permanently mapped also to kernel. In case or relocs only push buffer needs to be temporarily mapped to kernel. Ultimately even relocs are not necessary if we expose GPU virtual addresses directly to user space. But that's another topic. >>> Nouveau already exposes constant virtual addresses to userspace and >>> skips the pushbuf patching when the presumed offset from userspace is >>> the same as what the kernel thinks it should be. >>> >>> The problem with lowmem on ARM is that you can't unmap those pages from >>> the kernel cached mapping. So if you alloc a page, give it to userspace >>> and userspace decides to map the page WC you just produced a conflicting >>> mapping, which may yield undefined results on ARMv7. You may think this >>> is not a problem as you are not touching the kernel cached mapping, but >>> in fact it is. The CPUs prefetcher can still access this mapping. >> >> Why would this memory be mapped into the kernel? > > On ARM the kernel keeps a linear mapping of lowmem using sections > (ARM's version of huge pages). This is always cached, and because the > sections are not 4k, it's a pain to remove parts of it. See > arch/arm/mm/mmu.c Ah, are we talking about the directly-mapped low memory region starting at PAGE_OFFSET? Ok, it makes sense now, thanks. But it seems to me that such different mappings can also happen in many other scenarios as well, don't they? How is the issue handled in these cases? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 0/3] Shrinkers and proportional reclaim
On Mon, May 26, 2014 at 02:44:29PM -0700, Hugh Dickins wrote: > On Thu, 22 May 2014, Mel Gorman wrote: > > > This series is aimed at regressions noticed during reclaim activity. The > > first two patches are shrinker patches that were posted ages ago but never > > merged for reasons that are unclear to me. I'm posting them again to see if > > there was a reason they were dropped or if they just got lost. Dave? Time? > > The last patch adjusts proportional reclaim. Yuanhan Liu, can you retest > > the vm scalability test cases on a larger machine? Hugh, does this work > > for you on the memcg test cases? > > Yes it does, thank you. > > Though the situation is muddy, since on our current internal tree, I'm > surprised to find that the memcg test case no longer fails reliably > without our workaround and without your fix. > > "Something must have changed"; but it would take a long time to work > out what. If I travel back in time with git, to where we first applied > the "vindictive" patch, then yes that test case convincingly fails > without either (my or your) patch, and passes with either patch. > > And you have something that satisfies Yuanhan too, that's great. > > I'm also pleased to see Dave and Tim reduce the contention in > grab_super_passive(): that's a familiar symbol from livelock dumps. > > You might want to add this little 4/3, that we've had in for a > while; but with grab_super_passive() out of super_cache_count(), > it will have much less importance. > > > [PATCH 4/3] fs/superblock: Avoid counting without __GFP_FS > > Don't waste time counting objects in super_cache_count() if no __GFP_FS: > super_cache_scan() would only back out with SHRINK_STOP in that case. > > Signed-off-by: Hugh Dickins While you might think that's a good thing, it's not. The act of shrinking is kept separate from the accounting of how much shrinking needs to take place. The amount of work the shrinker can't do due to the reclaim context is deferred until the shrinker is called in a context where it can do work (eg. kswapd) Hence not accounting for work that can't be done immediately will adversely impact the balance of the system under memory intensive filesystem workloads. In these worklaods, almost all allocations are done in the GFP_NOFS or GFP_NOIO contexts so not deferring the work will will effectively stop superblock cache reclaim entirely Cheers, Dave. -- Dave Chinner da...@fromorbit.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Input: atmel_mxt_ts - fix build error in mxt_read_t9_resolution
On Tue, May 20, 2014 at 10:26:51AM +0100, Nick Dyer wrote: > Stephen Rothwell reports this build error: > > drivers/input/touchscreen/atmel_mxt_ts.c: In function > 'mxt_read_t9_resolution': > drivers/input/touchscreen/atmel_mxt_ts.c:1043:2: warning: passing argument 1 > of '__swab16s' makes pointer from integer without a cast [enabled by default] > le16_to_cpus(range.x); > ^ > > I believe this is a correct fix. > > Signed-off-by: Nick Dyer > --- > drivers/input/touchscreen/atmel_mxt_ts.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/input/touchscreen/atmel_mxt_ts.c > b/drivers/input/touchscreen/atmel_mxt_ts.c > index d8ea3ed..97495c7 100644 > --- a/drivers/input/touchscreen/atmel_mxt_ts.c > +++ b/drivers/input/touchscreen/atmel_mxt_ts.c > @@ -1040,8 +1040,8 @@ static int mxt_read_t9_resolution(struct mxt_data *data) > if (error) > return error; > > - le16_to_cpus(range.x); > - le16_to_cpus(range.y); > + le16_to_cpus(); > + le16_to_cpus(); > > error = __mxt_read_reg(client, > object->start_address + MXT_T9_ORIENT, > -- > 1.8.3.2 > Thank you, I folded it into the offending patch. -- 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/
linux-next: manual merge of the vfs tree with the ext4 tree
Hi Al,
Today's linux-next merge of the vfs tree got a conflict in
fs/ext4/file.c between commit 00532604c72e ("ext4: introduce new
i_write_mutex to protect fallocate") from the ext4 tree and commit
9b884164d597 ("convert ext4 to ->write_iter()") from the vfs tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc fs/ext4/file.c
index 8c39305abc23,708aad768199..
--- a/fs/ext4/file.c
+++ b/fs/ext4/file.c
@@@ -101,13 -97,10 +97,12 @@@ ext4_file_write_iter(struct kiocb *iocb
struct blk_plug plug;
int o_direct = file->f_flags & O_DIRECT;
int overwrite = 0;
- size_t length = iov_length(iov, nr_segs);
+ size_t length = iov_iter_count(from);
ssize_t ret;
-
- BUG_ON(iocb->ki_pos != pos);
+ loff_t pos = iocb->ki_pos;
+ mutex_lock(_I(inode)->i_write_mutex);
+
/*
* Unaligned direct AIO must be serialized; see comment above
* In the case of O_APPEND, assume that we must always serialize
@@@ -116,8 -109,9 +111,8 @@@
ext4_test_inode_flag(inode, EXT4_INODE_EXTENTS) &&
!is_sync_kiocb(iocb) &&
(file->f_flags & O_APPEND ||
-ext4_unaligned_aio(inode, iov, nr_segs, pos))) {
+ext4_unaligned_aio(inode, from, pos))) {
- aio_mutex = ext4_aio_mutex(inode);
- mutex_lock(aio_mutex);
+ unaligned_direct_aio = true;
ext4_unwritten_wait(inode);
}
@@@ -181,10 -172,8 +174,10 @@@
}
}
- ret = __generic_file_aio_write(iocb, iov, nr_segs);
+ ret = __generic_file_write_iter(iocb, from);
mutex_unlock(>i_mutex);
+ if (!unaligned_direct_aio)
+ mutex_unlock(_I(inode)->i_write_mutex);
if (ret > 0) {
ssize_t err;
signature.asc
Description: PGP signature
Re: [PATCH 14/14] perf tests: Add test for closing dso objects on EMFILE error
On Thu, 15 May 2014 19:23:35 +0200, Jiri Olsa wrote:
> Testing that perf properly closes opened dso objects
> and tries to reopen in case we run out of allowed file
> descriptors for dso data.
>
> Cc: Arnaldo Carvalho de Melo
> Cc: Corey Ashford
> Cc: David Ahern
> Cc: Frederic Weisbecker
> Cc: Ingo Molnar
> Cc: Jean Pihet
> Cc: Namhyung Kim
> Cc: Paul Mackerras
> Cc: Peter Zijlstra
> Signed-off-by: Jiri Olsa
> ---
> tools/perf/tests/builtin-test.c | 4 +++
> tools/perf/tests/dso-data.c | 70
> +
> tools/perf/tests/tests.h| 1 +
> 3 files changed, 75 insertions(+)
>
> diff --git a/tools/perf/tests/builtin-test.c b/tools/perf/tests/builtin-test.c
> index c4d581a..a489cda 100644
> --- a/tools/perf/tests/builtin-test.c
> +++ b/tools/perf/tests/builtin-test.c
> @@ -60,6 +60,10 @@ static struct test {
> .func = test__dso_data_cache,
> },
> {
> + .desc = "Test dso data reopen",
> + .func = test__dso_data_reopen,
> + },
> + {
> .desc = "roundtrip evsel->name check",
> .func = test__perf_evsel__roundtrip_name_test,
> },
> diff --git a/tools/perf/tests/dso-data.c b/tools/perf/tests/dso-data.c
> index 84ab939..ecc8acd 100644
> --- a/tools/perf/tests/dso-data.c
> +++ b/tools/perf/tests/dso-data.c
> @@ -328,3 +328,73 @@ int test__dso_data_cache(void)
> TEST_ASSERT_VAL("failed leadking files", nr == open_files_cnt());
> return 0;
> }
> +
> +int test__dso_data_reopen(void)
> +{
> + struct machine machine;
> + long nr = open_files_cnt();
> +#define BUFSIZE 10
Looks like a copy-n-paste error.. :)
> + int fd, fd_extra;
> +
> + memset(, 0, sizeof(machine));
> +
> + /*
> + * Test scenario:
> + * - create 3 dso objects
> + * - set process file descriptor limit to current
> + * files count + 3
> + * - test that the first dso gets closed when we
> + * reach the files count limit
> + */
> +
> + /* Make sure we are able to open 3 fds anyway */
> + TEST_ASSERT_VAL("failed to set file limit",
> + !set_fd_limit((nr + 3)));
> +
> + TEST_ASSERT_VAL("failed to create dsos\n",
> !dsos__create(TEST_FILE_SIZE));
> +
> + /* open dso_0 */
> + fd = dso__data_fd(dso_0, );
> + TEST_ASSERT_VAL("failed to get fd", fd > 0);
> +
> + /* open dso_1 */
> + fd = dso__data_fd(dso_1, );
> + TEST_ASSERT_VAL("failed to get fd", fd > 0);
> +
> + /*
> + * open extra file descriptor and we just
> + * reached the files count limit
> + */
> + fd_extra = open("/dev/null", O_RDONLY);
> + TEST_ASSERT_VAL("failed to open extra fd", fd_extra > 0);
> +
> + /* open dso_2 */
> + fd = dso__data_fd(dso_2, );
> + TEST_ASSERT_VAL("failed to get fd", fd > 0);
> +
> + /*
> + * dso_0 should get closed, because we reached
> + * the file descriptor limit
> + */
> + TEST_ASSERT_VAL("failed to close dso_0", dso_0->data.fd == -1);
> +
> + /* open dso_0 */
> + fd = dso__data_fd(dso_0, );
> + TEST_ASSERT_VAL("failed to get fd", fd > 0);
> +
> + /*
> + * dso_1 should get closed, because we reached
> + * the file descriptor limit
> + */
> + TEST_ASSERT_VAL("failed to close dso_0", dso_1->data.fd == -1);
s/dso_0/dso_1/
Btw, I don't see a big difference between this and previous testcase.
Any chance to merge them into one?
Thanks,
Namhyung
> +
> + /* cleanup everything */
> + close(fd_extra);
> + dsos__delete();
> +
> + pr_debug("nr start %ld, nr stop %ld\n", nr, open_files_cnt());
> +
> + /* Make sure we did not leak any file descriptor. */
> + TEST_ASSERT_VAL("failed leadking files", nr == open_files_cnt());
> + return 0;
> +}
> diff --git a/tools/perf/tests/tests.h b/tools/perf/tests/tests.h
> index 61e12b6..3247ca1 100644
> --- a/tools/perf/tests/tests.h
> +++ b/tools/perf/tests/tests.h
> @@ -29,6 +29,7 @@ int test__pmu(void);
> int test__attr(void);
> int test__dso_data(void);
> int test__dso_data_cache(void);
> +int test__dso_data_reopen(void);
> int test__parse_events(void);
> int test__hists_link(void);
> int test__python_use(void);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: fs/dcache.c - BUG: soft lockup - CPU#5 stuck for 22s! [systemd-udevd:1667]
On Mon, May 26, 2014 at 01:24:52PM -0700, Linus Torvalds wrote:
> Two things.
>
> (1) The facts.
>
> Just check the callchains on every single CPU in Mika's original email.
Point.
> (2) The code.
>
> Yes, the whole looping over the dentry tree happens in other places
> too, but shrink_dcache_parents() is already called under s_umount
But that one's not true. shrink_dcache_parent() is called from all kinds
of places, and it isn't guaranteed to be serialized at all.
For example, d_invalidate() will do it, and I wouldn't be surprised
to see it called in environment where we see shitloads of ->d_revalidate()
hitting dentries that ought to be invalidated. In fact, unless we have
something mounted under sysfs, those calls of check_submounts_and_drop()
will be followed by d_invalidate().
> > I really, really wonder WTF is causing that - we have spent 20-odd
> > seconds spinning while dentries in there were being evicted by
> > something. That - on sysfs, where dentry_kill() should be non-blocking
> > and very fast. Something very fishy is going on and I'd really like
> > to understand the use pattern we are seeing there.
>
> I think it literally is just a livelock. Just look at the NMI
> backtraces for each stuck CPU: most of them are waiting for the dentry
> lock in d_walk(). They have probably all a few dentries on their own
> list. One of the CPU is actually _in_ shrink_dentry_list().
>
> Now, the way our ticket spinlocks work, they are actually fair: which
> means that I can easily imagine us getting into a pattern, where if
> you have the right insane starting conditions, each CPU will basically
> get their own dentry list.
>
> That said, the only way I can see that nobody ever makes any progress
> is if somebody as the inode locked, and then dentry_kill() turns into
> a no-op. Otherwise one of those threads should always kill one or more
> dentries, afaik. We do have that "trylock on i_lock, then trylock on
> parent->d_lock", and if either of those fails, drop and re-try loop. I
> wonder if we can get into a situation where lots of people hold each
> others dentries locks sufficiently that dentry_kill() just ends up
> failing and looping..
Umm... Let me see if I understood you correctly - you think that it's
shrink_dentry_list() cycling through a bunch of dentries, failing trylocks
on all of them due to d_walk() from other threads that keeps hitting ->d_lock
on parents (->i_lock is less likely, AFAICS). Then we move the sucker
to the end of shrink list and try the next one, ad infinitum. And those
d_walk() callers keep looping since they keep finding those dentries and
nothing else... Right?
It looks plausible, but I doubt that serializing check_submounts_and_drop()
will suffice - shrink_dcache_parent() is just as unpleasant and it *is*
triggered in the same situations. Moreover, the lack of loop in memory
shrinkers doesn't help - we might get shrink_dentry_list() from one of
those and loops that keep calling d_walk() from check_submounts_and_drop()
or shrink_dcache_parent()...
> Anyway, I'd like Mika to test the stupid "let's serialize the dentry
> shrinking in check_submounts_and_drop()" to see if his problem goes
> away. I agree that it's not the _proper_ fix, but we're damn late in
> the rc series..
That we are... FWIW, if the nastiness matches the description above,
the right place to do something probably would be when those two
suckers get positive return value from d_walk() along with an empty
shrink list. I wonder if we should do down_read() in shrink_dentry_list()
and down_write();up_write() in that case in shrink_dcache_parent() and
check_submounts_and_drop(). How about the following?
diff --git a/fs/dcache.c b/fs/dcache.c
index 42ae01e..72f2c95 100644
--- a/fs/dcache.c
+++ b/fs/dcache.c
@@ -795,7 +795,14 @@ EXPORT_SYMBOL(d_prune_aliases);
static void shrink_dentry_list(struct list_head *list)
{
struct dentry *dentry, *parent;
+ static DECLARE_RWSEM(shrink_sem);
+ if (unlikely(list_empty(list))) {
+ down_write(_sem);
+ up_write(_sem);
+ return;
+ }
+ down_read(_sem);
while (!list_empty(list)) {
dentry = list_entry(list->prev, struct dentry, d_lru);
spin_lock(>d_lock);
@@ -842,6 +849,7 @@ static void shrink_dentry_list(struct list_head *list)
while (dentry && !lockref_put_or_lock(>d_lockref))
dentry = dentry_kill(dentry, 1);
}
+ up_read(_sem);
}
static enum lru_status
@@ -923,7 +931,8 @@ long prune_dcache_sb(struct super_block *sb, unsigned long
nr_to_scan,
freed = list_lru_walk_node(>s_dentry_lru, nid, dentry_lru_isolate,
, _to_scan);
- shrink_dentry_list();
+ if (!list_empty())
+ shrink_dentry_list();
return freed;
}
@@ -966,7 +975,8 @@ void shrink_dcache_sb(struct super_block *sb)
Re: [PATCH 13/14] perf tests: Add test for caching dso file descriptors
On Thu, 15 May 2014 19:23:34 +0200, Jiri Olsa wrote:
> Adding test that setup test_dso_data__fd_limit and test
> dso data file descriptors are cached appropriately.
[SNIP]
> +static long open_files_cnt(void)
> +{
> + char path[PATH_MAX];
> + struct dirent *dent;
> + DIR *dir;
> + long nr = 0;
> + int n;
> +
> + n = scnprintf(path, PATH_MAX, "%s/self/fd", procfs__mountpoint());
> + TEST_ASSERT_VAL("couldn't get fd path", n < PATH_MAX);
Looks like an unnecessary check since the scnprintf() cannot return more
than (or equal to) PATH_MAX.
> +
> + pr_debug("fd path: %s\n", path);
> +
> + dir = opendir(path);
> + TEST_ASSERT_VAL("failed to open fd directory", dir);
> +
> + while ((dent = readdir(dir)) != NULL) {
> + if (!strcmp(dent->d_name, ".") ||
> + !strcmp(dent->d_name, ".."))
> + continue;
> +
> + nr++;
> + }
> +
> + closedir(dir);
> + return nr - 1;
> +}
[SNIP]
> +static int set_fd_limit(int n)
> +{
> + struct rlimit rlim;
> +
> + if (getrlimit(RLIMIT_NOFILE, ))
> + return -1;
> +
> + pr_debug("file limit %ld, new %d\n", (long) rlim.rlim_cur, n);
> +
> + rlim.rlim_cur = n;
> + return setrlimit(RLIMIT_NOFILE, );
> +}
> +
> +int test__dso_data_cache(void)
> +{
> + struct machine machine;
> + long nr = open_files_cnt();
> +#define BUFSIZE 10
> + u8 buf[BUFSIZE];
> + ssize_t n;
> + int fd;
> +
> + memset(, 0, sizeof(machine));
> +
> + /* Make sure we are able to open 3 fds anyway */
> + TEST_ASSERT_VAL("failed to set file limit",
> + !set_fd_limit((nr + 6)));
3 or 6?
> +
> + /*
> + * Test scenario:
> + * - create 3 dso objects
> + * - set the limit of opened data file descriptors to 2
> + * - open/close dsos data fds and check for proper
> + * handling of the dso data cache
> + */
> +
> + test_dso_data__fd_limit = 3;
2 or 3?
> +
> + TEST_ASSERT_VAL("failed to create dsos\n",
> !dsos__create(TEST_FILE_SIZE));
> +
> + /* open dso_0 */
> + fd = dso__data_fd(dso_0, );
> + TEST_ASSERT_VAL("failed to get fd", fd > 0);
> +
> + n = dso__data_read_offset(dso_0, , 0, buf, BUFSIZE);
> + TEST_ASSERT_VAL("failed to read dso", n == BUFSIZE);
> +
> + /*
> + * Close dso_0 data with cache = true,
What does it mean by 'cache = true'?
> + * dso_0 should remain open.
> + */
> + dso__data_close(dso_0);
> + TEST_ASSERT_VAL("failed to not close dso", dso_0->data.fd != -1);
> +
> + /* open dso_1 */
> + n = dso__data_read_offset(dso_1, , 0, buf, BUFSIZE);
> + TEST_ASSERT_VAL("failed to read dso", n == BUFSIZE);
> +
> + /*
> + * Close dso_1 data with cache = true,
> + * dso_0 and dso_1 should remain open.
> + */
> + dso__data_close(dso_1);
> + TEST_ASSERT_VAL("failed to not close dso", dso_0->data.fd != -1);
> + TEST_ASSERT_VAL("failed to not close dso", dso_1->data.fd != -1);
> +
> + /* open dso_2 */
> + fd = dso__data_fd(dso_2, );
> + TEST_ASSERT_VAL("failed to get fd", fd > 0);
> +
> + /*
> + * Close dso_1 data with cache = true,
You meant dso_2 right? :)
Thanks,
Namhyung
> + * dso_0 should get closed now
> + */
> + dso__data_close(dso_2);
> + TEST_ASSERT_VAL("failed to close dso_0", dso_0->data.fd == -1);
> +
> + /* reopen dso_0 */
> + fd = dso__data_fd(dso_0, );
> + TEST_ASSERT_VAL("failed to get fd", fd > 0);
> +
> + /*
> + * Close dso_0 data with cache = true,
> + * dso_1 should get closed now.
> + */
> + dso__data_close(dso_0);
> + TEST_ASSERT_VAL("failed to close dso_1", dso_1->data.fd == -1);
> +
> + /* reopen dso_1 */
> + n = dso__data_read_offset(dso_1, , 0, buf, BUFSIZE);
> + TEST_ASSERT_VAL("failed to read dso", n == BUFSIZE);
> +
> + /*
> + * Close dso_1 data with cache = true,
> + * dso_2 should get closed now.
> + */
> + dso__data_close(dso_1);
> + TEST_ASSERT_VAL("failed to close dso_2", dso_2->data.fd == -1);
> +
> + /* dso_0 remains open */
> + TEST_ASSERT_VAL("failed to keep open dso_0", dso_0->data.fd >= 0);
> +
> + /* cleanup everything */
> + dsos__delete();
> +
> + pr_debug("nr start %ld, nr stop %ld\n", nr, open_files_cnt());
> +
> + /* Make sure we did not leak any file descriptor. */
> + TEST_ASSERT_VAL("failed leadking files", nr == open_files_cnt());
> + return 0;
> +}
> diff --git a/tools/perf/tests/tests.h b/tools/perf/tests/tests.h
> index a9d7cb0..61e12b6 100644
> --- a/tools/perf/tests/tests.h
> +++ b/tools/perf/tests/tests.h
> @@ -28,6 +28,7 @@ int test__syscall_open_tp_fields(void);
> int test__pmu(void);
> int test__attr(void);
> int test__dso_data(void);
> +int test__dso_data_cache(void);
> int test__parse_events(void);
> int test__hists_link(void);
> int test__python_use(void);
--
To unsubscribe
Re: [lxc-devel] [RFC PATCH 11/11] loop: Allow priveleged operations for root in the namespace which owns a device
Quoting Michael H. Warfield (m...@wittsend.com): > On Mon, 2014-05-26 at 11:16 +0200, Seth Forshee wrote: > > On Fri, May 23, 2014 at 08:48:25AM +0300, Marian Marinov wrote: > > > -BEGIN PGP SIGNED MESSAGE- > > > Hash: SHA1 > > > > > > One question about this patch. > > > > > > Why don't you use the devices cgroup check if the root user in that > > > namespace is allowed to use this device? > > > > > > This way you can be sure that the root in that namespace can not access > > > devices to which the host system did not gave > > > him access to. > > > That might be possible, but I don't want to require something on the > > host to whitelist the device for the container. Then loop would need to > > automatically add the device to devices.allow, which doesn't seem > > desirable to me. But I'm not entirely opposed to the idea if others > > think this is a better way to go. > > I don't see any safe way to avoid it. The host has to be in control of > what devices can and can not be accessed by the container. Disagree. loop%d is meaningless until it is attached to a file. So whether a container can use loop2 vs loop9 is meaningless. The point of Seth's loopfs as I understood it is that the container simply gets a unique (not visible to host or any other containers) set of loop devices which it can attach to files which it owns. So long as the host can't see the container's loop devices (i.e. so it unwittently mounts it when looking for a particular UUID for /var), it won't get fooled by them. So in this case *if* we can do it, a purely namespaced approach - meaning that we restrict visibility of a particular loopdev to one container - is perfect. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/4] get_maintainer: shut up perl critic
On Mon, 2014-05-26 at 18:22 -0700, Stephen Hemminger wrote: > Use the no critic annotation, with comment, to silence perl critic > for places where the code is correct as is. I think this uglifies the code and a more sensible solution is not using perlcritic -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] UniCore32: Change git tree location information in MAINTAINERS
From: Guan Xuetao UniCore32 git repo has moved to github. Branch 'unicore32' is used for prepared patches, and automatically merged to linux-next. Branch 'unicore32-working' is used for development. Signed-off-by: Guan Xuetao --- MAINTAINERS |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index 764075d..6d59899 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -6885,7 +6885,7 @@ PKUNITY SOC DRIVERS M: Guan Xuetao W: http://mprc.pku.edu.cn/~guanxuetao/linux S: Maintained -T: git git://git.kernel.org/pub/scm/linux/kernel/git/epip/linux-2.6-unicore32.git +T: git git://github.com/gxt/linux.git F: drivers/input/serio/i8042-unicore32io.h F: drivers/i2c/busses/i2c-puv3.c F: drivers/video/fb-puv3.c @@ -9165,7 +9165,7 @@ UNICORE32 ARCHITECTURE: M: Guan Xuetao W: http://mprc.pku.edu.cn/~guanxuetao/linux S: Maintained -T: git git://git.kernel.org/pub/scm/linux/kernel/git/epip/linux-2.6-unicore32.git +T: git git://github.com/gxt/linux.git F: arch/unicore32/ UNIFDEF -- 1.7.0.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [f2fs-dev] [PATCH v2] f2fs: avoid crash when trace f2fs_submit_page_mbio event in ra_sum_pages
Hi, Chao
Could you think about following once.
move node_inode in front of build_segment_manager, then use node_inode
instead of bd_inode.
On Tue, May 27, 2014 at 08:41:07AM +0800, Chao Yu wrote:
> Previously we allocate pages with no mapping in ra_sum_pages(), so we may
> encounter a crash in event trace of f2fs_submit_page_mbio where we access
> mapping data of the page.
>
> We'd better allocate pages in bd_inode mapping and invalidate these pages
> after
> we restore data from pages. It could avoid crash in above scenario.
>
> Changes from V1
> o remove redundant code in ra_sum_pages() suggested by Jaegeuk Kim.
>
> Call Trace:
> [] ? ftrace_raw_event_f2fs_write_checkpoint+0x80/0x80 [f2fs]
> [] f2fs_submit_page_mbio+0x1cb/0x200 [f2fs]
> [] restore_node_summary+0x13a/0x280 [f2fs]
> [] build_curseg+0x2bd/0x620 [f2fs]
> [] build_segment_manager+0x1cb/0x920 [f2fs]
> [] f2fs_fill_super+0x535/0x8e0 [f2fs]
> [] mount_bdev+0x16a/0x1a0
> [] f2fs_mount+0x1f/0x30 [f2fs]
> [] mount_fs+0x36/0x170
> [] vfs_kern_mount+0x55/0xe0
> [] do_mount+0x1e8/0x900
> [] SyS_mount+0x82/0xc0
> [] sysenter_do_call+0x12/0x22
>
> Suggested-by: Jaegeuk Kim
> Signed-off-by: Chao Yu
> ---
> fs/f2fs/node.c | 52
> 1 file changed, 24 insertions(+), 28 deletions(-)
>
> diff --git a/fs/f2fs/node.c b/fs/f2fs/node.c
> index 3d60d3d..02a59e9 100644
> --- a/fs/f2fs/node.c
> +++ b/fs/f2fs/node.c
> @@ -1658,35 +1658,29 @@ int recover_inode_page(struct f2fs_sb_info *sbi,
> struct page *page)
>
> /*
> * ra_sum_pages() merge contiguous pages into one bio and submit.
> - * these pre-readed pages are linked in pages list.
> + * these pre-readed pages are alloced in bd_inode's mapping tree.
> */
> -static int ra_sum_pages(struct f2fs_sb_info *sbi, struct list_head *pages,
> +static int ra_sum_pages(struct f2fs_sb_info *sbi, struct page **pages,
> int start, int nrpages)
> {
> - struct page *page;
> - int page_idx = start;
> + struct inode *inode = sbi->sb->s_bdev->bd_inode;
> + struct address_space *mapping = inode->i_mapping;
> + int i, page_idx = start;
> struct f2fs_io_info fio = {
> .type = META,
> .rw = READ_SYNC | REQ_META | REQ_PRIO
> };
>
> - for (; page_idx < start + nrpages; page_idx++) {
> - /* alloc temporal page for read node summary info*/
> - page = alloc_page(GFP_F2FS_ZERO);
> - if (!page)
> + for (i = 0; page_idx < start + nrpages; page_idx++, i++) {
> + /* alloc page in bd_inode for reading node summary info */
> + pages[i] = grab_cache_page(mapping, page_idx);
> + if (!pages[i])
> break;
> -
> - lock_page(page);
> - page->index = page_idx;
> - list_add_tail(>lru, pages);
> + f2fs_submit_page_mbio(sbi, pages[i], page_idx, );
> }
>
> - list_for_each_entry(page, pages, lru)
> - f2fs_submit_page_mbio(sbi, page, page->index, );
> -
> f2fs_submit_merged_bio(sbi, META, READ);
> -
> - return page_idx - start;
> + return i;
> }
>
> int restore_node_summary(struct f2fs_sb_info *sbi,
> @@ -1694,11 +1688,11 @@ int restore_node_summary(struct f2fs_sb_info *sbi,
> {
> struct f2fs_node *rn;
> struct f2fs_summary *sum_entry;
> - struct page *page, *tmp;
> + struct inode *inode = sbi->sb->s_bdev->bd_inode;
> block_t addr;
> int bio_blocks = MAX_BIO_BLOCKS(max_hw_blocks(sbi));
> - int i, last_offset, nrpages, err = 0;
> - LIST_HEAD(page_list);
> + struct page *pages[bio_blocks];
> + int i, idx, last_offset, nrpages, err = 0;
>
> /* scan the node segment */
> last_offset = sbi->blocks_per_seg;
> @@ -1709,29 +1703,31 @@ int restore_node_summary(struct f2fs_sb_info *sbi,
> nrpages = min(last_offset - i, bio_blocks);
>
> /* read ahead node pages */
> - nrpages = ra_sum_pages(sbi, _list, addr, nrpages);
> + nrpages = ra_sum_pages(sbi, pages, addr, nrpages);
> if (!nrpages)
> return -ENOMEM;
>
> - list_for_each_entry_safe(page, tmp, _list, lru) {
> + for (idx = 0; idx < nrpages; idx++) {
> if (err)
> goto skip;
>
> - lock_page(page);
> - if (unlikely(!PageUptodate(page))) {
> + lock_page(pages[idx]);
> + if (unlikely(!PageUptodate(pages[idx]))) {
> err = -EIO;
> } else {
> - rn = F2FS_NODE(page);
> + rn = F2FS_NODE(pages[idx]);
> sum_entry->nid = rn->footer.nid;
> sum_entry->version = 0;
>
RE: [PATCHv5 0/2] imx2-wdt: Add regmap-mmio support
> > Xiubo Li (2): > > watchdog: imx2_wdt: Sort the header files alphabetically > > watchdog: imx2_wdt: convert to use regmap API. > > > > drivers/watchdog/Kconfig| 1 + > > drivers/watchdog/imx2_wdt.c | 62 +++--- > --- > > 2 files changed, 39 insertions(+), 24 deletions(-) > > both patches have been added to linux-watchdog-next. > Thanks very much, BRs Xiubo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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/4] get_maintainer: shut up perl critic
Use the no critic annotation, with comment, to silence perl critic
for places where the code is correct as is.
Signed-off-by: Stephen Hemminger
---
Supersedes patch 1
--- a/scripts/get_maintainer.pl 2014-05-26 18:09:38.257783683 -0700
+++ b/scripts/get_maintainer.pl 2014-05-26 18:19:25.782478516 -0700
@@ -231,7 +231,10 @@ if ($version != 0) {
exit 0;
}
+# For this usage requiring IO::Interactive is overkill
+## no critic (ProhibitInteractiveTest)
if (-t STDIN && !@ARGV) {
+## use critic
# We're talking to a terminal, but have no command line arguments.
die "$P: missing patchfile or -f file - use --help if necessary\n";
}
@@ -423,8 +426,13 @@ foreach my $file (@ARGV) {
my $file_cnt = @files;
my $lastfile;
+ # Use two argument form of open because we want
+ # to allow using "-" to indicate standard input
+
+ ## no critic (ProhibitTwoArgOpen)
open(my $patch, "< $file")
or die "$P: Can't open $file: $!\n";
+ ## use critic
# We can check arbitrary information before the patch
# like the commit message, mail headers, etc...
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 12/14] perf tests: Add test interface for dso data fd limit
On Thu, 15 May 2014 19:23:33 +0200, Jiri Olsa wrote:
> Adding a way to setup test dso limit by global variable
> test_dso_data__fd_limit. It'll be used in the dso data
> cache tests.
Why is this needed? Why not justing setting RLIMIT_NOFILE in the test
cases?
Thanks,
Namhyung
>
> Cc: Arnaldo Carvalho de Melo
> Cc: Corey Ashford
> Cc: David Ahern
> Cc: Frederic Weisbecker
> Cc: Ingo Molnar
> Cc: Jean Pihet
> Cc: Namhyung Kim
> Cc: Paul Mackerras
> Cc: Peter Zijlstra
> Signed-off-by: Jiri Olsa
> ---
> tools/perf/util/dso.c | 5 +
> tools/perf/util/dso.h | 3 +++
> 2 files changed, 8 insertions(+)
>
> diff --git a/tools/perf/util/dso.c b/tools/perf/util/dso.c
> index 80b54e7..9310369 100644
> --- a/tools/perf/util/dso.c
> +++ b/tools/perf/util/dso.c
> @@ -7,6 +7,8 @@
> #include "util.h"
> #include "debug.h"
>
> +rlim_t test_dso_data__fd_limit;
> +
> char dso__symtab_origin(const struct dso *dso)
> {
> static const char origin[] = {
> @@ -262,6 +264,9 @@ static bool may_cache_fd(void)
> if (!limit)
> limit = get_fd_limit();
>
> + if (unlikely(test_dso_data__fd_limit))
> + limit = test_dso_data__fd_limit;
> +
> if (limit == RLIM_INFINITY)
> return true;
>
> diff --git a/tools/perf/util/dso.h b/tools/perf/util/dso.h
> index d713184..3807014 100644
> --- a/tools/perf/util/dso.h
> +++ b/tools/perf/util/dso.h
> @@ -1,6 +1,7 @@
> #ifndef __PERF_DSO
> #define __PERF_DSO
>
> +#include
> #include
> #include
> #include
> @@ -8,6 +9,8 @@
> #include "map.h"
> #include "build-id.h"
>
> +extern rlim_t test_dso_data__fd_limit;
> +
> enum dso_binary_type {
> DSO_BINARY_TYPE__KALLSYMS = 0,
> DSO_BINARY_TYPE__GUEST_KALLSYMS,
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 0/4] get_maintainer script cleanups
On Mon, 26 May 2014 18:03:55 -0700 Joe Perches wrote: > On Mon, 2014-05-26 at 18:00 -0700, Joe Perches wrote: > > On Mon, 2014-05-26 at 13:33 -0700, Stephen Hemminger wrote: > > > Some simple perl hacking changes. > > I think the first one breaks the code too. > > https://lkml.org/lkml/2010/3/10/50 > > Ah forgot that. Never used that form in my usage. Never mind. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[f2fs-dev][PATCH] f2fs: avoid overflow when large directory feathure is enabled
When large directory feathure is enable, We have one case which could cause
overflow in dir_buckets() as following:
special case: level + dir_level >= 32 and level < MAX_DIR_HASH_DEPTH / 2.
Here we define MAX_DIR_BUCKETS to limit the return value when the condition
could trigger potential overflow.
Signed-off-by: Chao Yu
---
fs/f2fs/dir.c |4 ++--
include/linux/f2fs_fs.h |3 +++
2 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/fs/f2fs/dir.c b/fs/f2fs/dir.c
index c3f1485..966acb0 100644
--- a/fs/f2fs/dir.c
+++ b/fs/f2fs/dir.c
@@ -23,10 +23,10 @@ static unsigned long dir_blocks(struct inode *inode)
static unsigned int dir_buckets(unsigned int level, int dir_level)
{
- if (level < MAX_DIR_HASH_DEPTH / 2)
+ if (level + dir_level < MAX_DIR_HASH_DEPTH / 2)
return 1 << (level + dir_level);
else
- return 1 << ((MAX_DIR_HASH_DEPTH / 2 + dir_level) - 1);
+ return MAX_DIR_BUCKETS;
}
static unsigned int bucket_blocks(unsigned int level)
diff --git a/include/linux/f2fs_fs.h b/include/linux/f2fs_fs.h
index 8c03f71..ba6f312 100644
--- a/include/linux/f2fs_fs.h
+++ b/include/linux/f2fs_fs.h
@@ -394,6 +394,9 @@ typedef __le32 f2fs_hash_t;
/* MAX level for dir lookup */
#define MAX_DIR_HASH_DEPTH 63
+/* MAX buckets in one level of dir */
+#define MAX_DIR_BUCKETS(1 << ((MAX_DIR_HASH_DEPTH / 2) - 1))
+
#define SIZE_OF_DIR_ENTRY 11 /* by byte */
#define SIZE_OF_DENTRY_BITMAP ((NR_DENTRY_IN_BLOCK + BITS_PER_BYTE - 1) / \
BITS_PER_BYTE)
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 10/14] perf tests: Spawn child for each test
On Thu, 15 May 2014 19:23:31 +0200, Jiri Olsa wrote: > In upcoming tests we will setup process limits, which > might affect other tests. Spawning child for each test > to prevent this. But you can restore original limits after the test using soft limits? But I think it's better to run the tests in a child anyway. :) Thanks, Namhyung -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [Nouveau] [RFC] drm/nouveau: disable caching for VRAM BOs on ARM
On Mon, May 26, 2014 at 5:02 PM, Alexandre Courbot wrote: > On Mon, May 26, 2014 at 6:21 PM, Lucas Stach wrote: >> Am Montag, den 26.05.2014, 09:45 +0300 schrieb Terje Bergström: >>> On 23.05.2014 17:40, Alex Courbot wrote: >>> > On 05/23/2014 06:59 PM, Lucas Stach wrote: >>> > So after checking with more knowledgeable people, it turns out this is >>> > the expected behavior on ARM and BAR regions should be mapped uncached >>> > on GK20A. All the more reasons to avoid using the BAR at all. >>> >>> This is actually specific to Tegra. >>> >>> >> You may want to make yourself aware of all the quirks required for >>> >> sharing memory between the GPU and CPU on an ARM host. I think there are >>> >> far more involved than what you see now and writing an replacement for >>> >> TTM will not be an easy task. >>> >> >>> >> Doing away with the concept of two memory areas will not get you to a >>> >> single unified address space. You would have to deal with things like >>> >> not being able to change the caching state of pages in the systems >>> >> lowmem yourself. You will still have to deal with remapping pages that >>> >> aren't currently visible to the CPU (ok this is not an issue on Jetson >>> >> right now as it only has 2GB of RAM), because it's in systems highmem, >>> >> or even in a different LPAE area. >>> >> >>> >> You really want to be sure you are aware of all the consequences of >>> >> this, before considering this task. >>> > >>> > Yep, that's why I am seeking advice here. My first hope is that with a >>> > few tweaks we will be able to keep using TTM and the current nouveau_bo >>> > implementation. But unless I missed something this is not going to be >>> > easy. >>> > >>> > We can also use something like the patch I originally sent to make it >>> > work, although not with good performance, on GK20A. Not very graceful, >>> > but it will allow applications to run. >>> > >>> > In the long run though, we will want to achieve better performance, and >>> > it seems like a BO implementation targeted at UMA devices would also be >>> > beneficial to quite a few desktop GPUs. So as tricky as it may be I'm >>> > interested in gathering thoughts and why not giving it a first try with >>> > GK20A, even if it imposes some limitations like having buffers in lowmem >>> > in a first time (we can probably live with this one for a short while, >>> > and 64 bits will also be coming to the rescue :)) >>> >>> I don't think lowmem or LPAE is any problem, if the memory manager is >>> designed with that in mind. Vast majority of the buffers kernel >>> allocates do not need to be touched in kernel space. >>> >>> Actually I can't think of any buffers that we allocate on behalf of user >>> space that would need to be permanently mapped also to kernel. In case >>> or relocs only push buffer needs to be temporarily mapped to kernel. >>> >>> Ultimately even relocs are not necessary if we expose GPU virtual >>> addresses directly to user space. But that's another topic. >>> >> Nouveau already exposes constant virtual addresses to userspace and >> skips the pushbuf patching when the presumed offset from userspace is >> the same as what the kernel thinks it should be. >> >> The problem with lowmem on ARM is that you can't unmap those pages from >> the kernel cached mapping. So if you alloc a page, give it to userspace >> and userspace decides to map the page WC you just produced a conflicting >> mapping, which may yield undefined results on ARMv7. You may think this >> is not a problem as you are not touching the kernel cached mapping, but >> in fact it is. The CPUs prefetcher can still access this mapping. > > Why would this memory be mapped into the kernel? On ARM the kernel keeps a linear mapping of lowmem using sections (ARM's version of huge pages). This is always cached, and because the sections are not 4k, it's a pain to remove parts of it. See arch/arm/mm/mmu.c That said, I don't think this issue exists on A15 (which is what those GPUs are paired with), so it's a purely theoretical problem. Stéphane -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 09/14] perf tools: Add dso__data_* interface descriptons
On Thu, 15 May 2014 19:23:30 +0200, Jiri Olsa wrote: [SNIP] > +/** > + * dso__data_read_addr - Read data from dso address > + * @dso: dso object > + * @machine: machine object > + * @offset: file offset s/offset/addr/ Thanks Namhyung > + * @data: buffer to store data > + * @size: size of the @data buffer > + * > + * Read data from dso address. > + */ > ssize_t dso__data_read_addr(struct dso *dso, struct map *map, > struct machine *machine, u64 addr, > u8 *data, ssize_t size) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 0/4] get_maintainer script cleanups
On Mon, 26 May 2014 18:00:49 -0700 Joe Perches wrote: > On Mon, 2014-05-26 at 13:33 -0700, Stephen Hemminger wrote: > > Some simple perl hacking changes. > > I don't really care for these. > > Why do you think these are better? > > I think the first one breaks the code too. > > $ perlcritic scripts/get_maintainer.pl Use IO::Interactive::is_interactive() instead of -t at line 237, column 5. See page 218 of PBP. (Severity: 5) Two-argument "open" used at line 429, column 2. See page 207 of PBP. (Severity: 5) Expression form of "eval" at line 1410, column 17. See page 161 of PBP. (Severity: 5) Expression form of "eval" at line 1412, column 17. See page 161 of PBP. (Severity: 5) If you read Perl Best Practices you will see why these are issues. The first is because the test for STDIN and ARGV is not sufficient to check for interactive usage. The next is because using quoted two arg open breaks if there is a space in name etc. Lastly eval of a string leads to runtime errors versus compile time. Yes, for a trivial program like this it really doesn't matter. But this program is likely to grow and be copied by other developers and I would like it to use current best practices. The same applies to all the other parts of the kernel. I tested each step, and they all work for me™ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 06/14] perf tools: Cache dso data file descriptor
Hi Jiri,
On Thu, 15 May 2014 19:23:27 +0200, Jiri Olsa wrote:
[SNIP]
> +static void data_close(void)
> +{
> + bool cache_fd = may_cache_fd();
> +
> + if (!cache_fd)
> + close_first_dso();
> +}
Why do you do this at close()? As long as there's no attempt to open a
new file, we can keep existing fd, no?
> +
> +void dso__data_close(struct dso *dso)
> +{
> + if (dso->data.fd >= 0)
> + data_close();
> +}
Hmm.. it's confusing dso__data_close(dso) closes an other dso rather
than the given dso. And this dso__data_close() is not paired with any
_open() also these close calls make me confusing which one to use. ;-p
Thanks
Namhyung
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 0/4] get_maintainer script cleanups
On Mon, 2014-05-26 at 18:00 -0700, Joe Perches wrote: > On Mon, 2014-05-26 at 13:33 -0700, Stephen Hemminger wrote: > > Some simple perl hacking changes. > I think the first one breaks the code too. https://lkml.org/lkml/2010/3/10/50 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] clk: shmobile: mstp: Fix the is_enabled() operation
On Fri, May 23, 2014 at 3:02 AM, Geert Uytterhoeven
wrote:
> From: Laurent Pinchart
>
> The MSTP[SC]R registers have clock stop bits, not clock enable bits. The
> bit value should thus be inverted in the is_enabled() operation.
>
> Signed-off-by: Laurent Pinchart
> Signed-off-by: Geert Uytterhoeven
> Cc: Mike Turquette
> ---
> v3:
> - This depends on commit 3c90c55dcde745bed81f6447f24ba96bda43d984
> ("drivers: sh: compile drivers/sh/pm_runtime.c if
> ARCH_SHMOBILE_MULTI"), which has entered mainline in v3.15-rc6.
Hi Geert,
Thanks for resubmitting this fix. Do you intend to get this included
in v3.15 (seems unlikely) or is your target v3.16?
Cheers,
/ magnus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 0/4] get_maintainer script cleanups
On Mon, 2014-05-26 at 13:33 -0700, Stephen Hemminger wrote: > Some simple perl hacking changes. I don't really care for these. Why do you think these are better? I think the first one breaks the code too. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/9] staging: ion: tidy up a bit
Hello Carpenter, On 05/26/2014 07:36 PM, Dan Carpenter wrote: On Mon, May 26, 2014 at 07:04:53PM +0900, Heesub Shin wrote: @@ -124,7 +122,6 @@ static struct page_info *alloc_largest_available(struct ion_system_heap *heap, info->page = page; info->order = orders[i]; - INIT_LIST_HEAD(>list); return info; } kfree(info); Wait. How does this code work without that INIT_LIST_HEAD()? What am I missing here... No problem. As the object info is just a node, not a head, it is completely useless to initialize it as a list head. regards, Heesub regards, dan carpenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
dringend Kredit @3 %
Grüße "UINFY CREDIT UNION" bietet einen breiten Rande des finanziellen Handels Kreditvergabe Dienstleistungen für Privatpersonen und co Betrieb stellen wir bieten Darlehen zu einem Zinssatz von 3 %. Wenn Sie finanzielle Hilfe angewiesen sind oder Darlehen an Ihre uneinbringliche Forderungen zu begleichen, werden Sie aufgefordert, unten füllen aus und kontaktieren Sie die Firma e-Mail (unify_uk_creditun...@zsk.name) für Ihre Kreditbearbeitung. Office Line: +447042033179 Vollständiger Name: Land: Kreditbetrag: Darlehen-Dauer: Ich erwarte Ihre Antwort um uns zu aktivieren gehen Sie mit der Kredit-Dokumentation Vielen Dank Mr. Whitney -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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/8] OF: Introduce DT overlay support.
On 05/26/2014 05:32 PM, Sebastian Reichel wrote: On Mon, May 26, 2014 at 04:42:44PM -0700, Guenter Roeck wrote: On 05/26/2014 03:36 PM, Sebastian Reichel wrote: On Mon, May 26, 2014 at 10:33:03PM +0100, Grant Likely wrote: After thinking about it more, I think it is very likely that removing all the overlays is the correct thing to do in the kexec use-case. When kexec-ing, it makes sense that we'd want the exact same behaviour from the kexec'ed kernel. That means we want the device drivers to do the same thing including loading whatever overlays they depend on. If the flattened tree was left applied, then the behaviour becomes different. I say always remove the overlays unless explicitly told not to, but I'm struggling to come up with use cases where keeping them applied is desirable. I would assume, that I want them applied in most cases. DT describes the hardware. If I kexec into a new kernel I change software, not hardware. Maybe I'm missing the main purpose of the feature. I currently see two useful usecases for DT overlays: 1. The dtb the kernel is booted with cannot be changed for some reason, but the board has additional hardware attached (e.g. the user added a sensor on the i2c bus) 2. The hardware is changed on the fly (e.g. the user flashed the FPGA part of a zynq processor), sensors on i2c bus, ... In both cases the kernel should be booted with the additional overlay information IMHO. Though for the second case it should be possible to remove the "programmed" hardware information somehow. 3. Some hot-plug device or card is inserted or removed. Can you give a more specific example? I guess most hot-plug devices are connected to busses, which are not described via DT, but support auto-identification (USB, PCI, ...) The card interface provides i2c and pcie busses, plus a number of gpio pins. Both I2C devices and PCIe devices depend on the inserted card type. There may be PCIe switches on some cards, or just PCIe devices on others. Auto-identification of PCIe devices does not help, as the device configuration depends on the card type inserted. A typical example is that the card may include a multi-function FPGA device with LED, GPIO, and I2C bus master functionality, and the specific configuration depends on the card type (even though the FPGA is the same). Other cards may include a PCIe switch with a number of ASICs connected to it. PCIe switch configuration depends on the card type, not on the PCIe switch type. I would argue that the kernel should _not_ be booted with the overlay in place. well the device is still attached to the system when you kexec into the new kernel, isn't it? So ? the code executed is ultimately the same, if the kernel is booted from rommon or from kexec. In one case we'll have to insert the overlay, in the other case not. Otherwise the code handling overlays would have to have special handling for the restart case, which is much more complex than just to re-insert the overlay when it is determined that the device or card is still there. I assume, that the kernel cannot auto-detect the attached hardware. Correct. Otherwise we don't need the DT entries, but can simply scan the bus. So the restart case (or restart + kexec case if kexec behaves like a restart) means, that userspace needs to provide the information about device existence. Exactly the same informatin we get if the kernel is booted from ROMMON or BIOS. No difference here. Removing the overlay is like dropping information supplied from the user. Not something, which should be done carelessly. In our case it is done when the card is removed. 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/
linux-next: manual merge of the arm-soc tree with the arm tree
Hi all,
Today's linux-next merge of the arm-soc tree got a conflict in
arch/arm/mach-zynq/common.c between commit e1e4ccb5b1b6 ("ARM: l2c:
zynq: convert to generic l2c OF initialisation") from the arm tree and
commit 00f7dc636366 ("ARM: zynq: Add support for SOC_BUS") from the
arm-soc tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc arch/arm/mach-zynq/common.c
index d1e992e6403e,edbd9d83f407..
--- a/arch/arm/mach-zynq/common.c
+++ b/arch/arm/mach-zynq/common.c
@@@ -66,8 -105,43 +105,38 @@@ static int __init zynq_get_revision(voi
static void __init zynq_init_machine(void)
{
struct platform_device_info devinfo = { .name = "cpufreq-cpu0", };
+ struct soc_device_attribute *soc_dev_attr;
+ struct soc_device *soc_dev;
+ struct device *parent = NULL;
+
- /*
- * 64KB way size, 8-way associativity, parity disabled
- */
- l2x0_of_init(0x0206, 0xF0F0);
-
+ soc_dev_attr = kzalloc(sizeof(*soc_dev_attr), GFP_KERNEL);
+ if (!soc_dev_attr)
+ goto out;
+
+ system_rev = zynq_get_revision();
+
+ soc_dev_attr->family = kasprintf(GFP_KERNEL, "Xilinx Zynq");
+ soc_dev_attr->revision = kasprintf(GFP_KERNEL, "0x%x", system_rev);
+ soc_dev_attr->soc_id = kasprintf(GFP_KERNEL, "0x%x",
+zynq_slcr_get_device_id());
+
+ soc_dev = soc_device_register(soc_dev_attr);
+ if (IS_ERR(soc_dev)) {
+ kfree(soc_dev_attr->family);
+ kfree(soc_dev_attr->revision);
+ kfree(soc_dev_attr->soc_id);
+ kfree(soc_dev_attr);
+ goto out;
+ }
+
+ parent = soc_device_to_device(soc_dev);
- of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
+ out:
+ /*
+* Finished with the static registrations now; fill in the missing
+* devices
+*/
+ of_platform_populate(NULL, of_default_bus_match_table, NULL, parent);
platform_device_register(_cpuidle_device);
platform_device_register_full();
signature.asc
Description: PGP signature
Re: [PATCH RESEND v2 1/4] mfd: intel_soc_pmic: Core driver
On 5/26/2014 10:51 PM, Mark Brown wrote: > On Mon, May 26, 2014 at 02:01:11PM +0800, Zhu, Lejun wrote: >> On 5/24/2014 1:49 AM, Mark Brown wrote: > >>> There should also be no need to add extra locking around regmap calls, >>> the regmap API has locking as standard. > >> Actually it also protects the pmic variable, so it won't be set to NULL >> while there's ongoing read/write. > > Righ, but there is no clear need for the pmic variable to exist in the > first place. > >>> It's also not clear why this API exists at all, surely all the >>> interaction with the device happens from the core or function drivers >>> for the device which ought to be able to get a direct reference to the >>> regmap anyway and only be instantiated when one is present. > >> We created these names to hide the implementation of how read/write is >> done from other platform specific patches interacting with this driver. >> So when we change the implementation, e.g. from I2C read/write to >> regmap, we don't have to touch all these patches. > > This sort of HAL is frowned upon in the upstream kernel. We want to do what other MFD drivers' been doing, and make it easier for the callers. A couple of similar examples are intel_msic_reg_read() and lp3943_read_byte(). We want to do the same with intel_soc_pmic_readb(), and I don't think it's too odd. Best Regards Lejun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: manual merge of the arm-soc tree with the arm tree
Hi all,
Today's linux-next merge of the arm-soc tree got a conflict in
arch/arm/mach-rockchip/rockchip.c between commit fc2553457ccd ("ARM:
l2c: rockchip: convert to generic l2c OF initialisation") from the arm
tree and commit 26ab69cb4c1f ("ARM: rockchip: convert smp bringup to
CPU_METHOD_OF_DECLARE") from the arm-soc tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc arch/arm/mach-rockchip/rockchip.c
index 138b9975313a,4499b0a31a27..
--- a/arch/arm/mach-rockchip/rockchip.c
+++ b/arch/arm/mach-rockchip/rockchip.c
@@@ -33,8 -39,6 +33,7 @@@ static const char * const rockchip_boar
};
DT_MACHINE_START(ROCKCHIP_DT, "Rockchip Cortex-A9 (Device Tree)")
- .init_machine = rockchip_dt_init,
+ .l2c_aux_val= 0,
+ .l2c_aux_mask = ~0,
- .smp= smp_ops(rockchip_smp_ops),
.dt_compat = rockchip_board_dt_compat,
MACHINE_END
signature.asc
Description: PGP signature
linux-next: manual merge of the arm-soc tree with the tree
Hi all,
Today's linux-next merge of the arm-soc tree got a conflict in
arch/arm/mach-omap2/omap-mpuss-lowpower.c between commit 4e4bb5c72f6b
("ARM: l2c: omap2: avoid reading directly from the L2 registers in
platform code") from the arm tree and commit edfaf05c2fcb ("ARM:
OMAP2+: raw read and write endian fix") from the arm-soc tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc arch/arm/mach-omap2/omap-mpuss-lowpower.c
index 61cb77f8cf12,eb76e47091ad..
--- a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
+++ b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
@@@ -187,15 -187,19 +187,15 @@@ static void l2x0_pwrst_prepare(unsigne
* in every restore MPUSS OFF path.
*/
#ifdef CONFIG_CACHE_L2X0
-static void save_l2x0_context(void)
+static void __init save_l2x0_context(void)
{
- __raw_writel(l2x0_saved_regs.aux_ctrl,
-sar_base + L2X0_AUXCTRL_OFFSET);
- __raw_writel(l2x0_saved_regs.prefetch_ctrl,
-sar_base + L2X0_PREFETCH_CTRL_OFFSET);
- u32 val;
- void __iomem *l2x0_base = omap4_get_l2cache_base();
- if (l2x0_base) {
- val = readl_relaxed(l2x0_base + L2X0_AUX_CTRL);
- writel_relaxed(val, sar_base + L2X0_AUXCTRL_OFFSET);
- val = readl_relaxed(l2x0_base + L2X0_PREFETCH_CTRL);
- writel_relaxed(val, sar_base + L2X0_PREFETCH_CTRL_OFFSET);
- }
++ writel_relaxed(l2x0_saved_regs.aux_ctrl,
++ sar_base + L2X0_AUXCTRL_OFFSET);
++ writel_relaxed(l2x0_saved_regs.prefetch_ctrl,
++ sar_base + L2X0_PREFETCH_CTRL_OFFSET);
}
#else
-static void save_l2x0_context(void)
+static void __init save_l2x0_context(void)
{}
#endif
signature.asc
Description: PGP signature
[f2fs-dev] [PATCH v2] f2fs: avoid crash when trace f2fs_submit_page_mbio event in ra_sum_pages
Previously we allocate pages with no mapping in ra_sum_pages(), so we may
encounter a crash in event trace of f2fs_submit_page_mbio where we access
mapping data of the page.
We'd better allocate pages in bd_inode mapping and invalidate these pages after
we restore data from pages. It could avoid crash in above scenario.
Changes from V1
o remove redundant code in ra_sum_pages() suggested by Jaegeuk Kim.
Call Trace:
[] ? ftrace_raw_event_f2fs_write_checkpoint+0x80/0x80 [f2fs]
[] f2fs_submit_page_mbio+0x1cb/0x200 [f2fs]
[] restore_node_summary+0x13a/0x280 [f2fs]
[] build_curseg+0x2bd/0x620 [f2fs]
[] build_segment_manager+0x1cb/0x920 [f2fs]
[] f2fs_fill_super+0x535/0x8e0 [f2fs]
[] mount_bdev+0x16a/0x1a0
[] f2fs_mount+0x1f/0x30 [f2fs]
[] mount_fs+0x36/0x170
[] vfs_kern_mount+0x55/0xe0
[] do_mount+0x1e8/0x900
[] SyS_mount+0x82/0xc0
[] sysenter_do_call+0x12/0x22
Suggested-by: Jaegeuk Kim
Signed-off-by: Chao Yu
---
fs/f2fs/node.c | 52
1 file changed, 24 insertions(+), 28 deletions(-)
diff --git a/fs/f2fs/node.c b/fs/f2fs/node.c
index 3d60d3d..02a59e9 100644
--- a/fs/f2fs/node.c
+++ b/fs/f2fs/node.c
@@ -1658,35 +1658,29 @@ int recover_inode_page(struct f2fs_sb_info *sbi, struct
page *page)
/*
* ra_sum_pages() merge contiguous pages into one bio and submit.
- * these pre-readed pages are linked in pages list.
+ * these pre-readed pages are alloced in bd_inode's mapping tree.
*/
-static int ra_sum_pages(struct f2fs_sb_info *sbi, struct list_head *pages,
+static int ra_sum_pages(struct f2fs_sb_info *sbi, struct page **pages,
int start, int nrpages)
{
- struct page *page;
- int page_idx = start;
+ struct inode *inode = sbi->sb->s_bdev->bd_inode;
+ struct address_space *mapping = inode->i_mapping;
+ int i, page_idx = start;
struct f2fs_io_info fio = {
.type = META,
.rw = READ_SYNC | REQ_META | REQ_PRIO
};
- for (; page_idx < start + nrpages; page_idx++) {
- /* alloc temporal page for read node summary info*/
- page = alloc_page(GFP_F2FS_ZERO);
- if (!page)
+ for (i = 0; page_idx < start + nrpages; page_idx++, i++) {
+ /* alloc page in bd_inode for reading node summary info */
+ pages[i] = grab_cache_page(mapping, page_idx);
+ if (!pages[i])
break;
-
- lock_page(page);
- page->index = page_idx;
- list_add_tail(>lru, pages);
+ f2fs_submit_page_mbio(sbi, pages[i], page_idx, );
}
- list_for_each_entry(page, pages, lru)
- f2fs_submit_page_mbio(sbi, page, page->index, );
-
f2fs_submit_merged_bio(sbi, META, READ);
-
- return page_idx - start;
+ return i;
}
int restore_node_summary(struct f2fs_sb_info *sbi,
@@ -1694,11 +1688,11 @@ int restore_node_summary(struct f2fs_sb_info *sbi,
{
struct f2fs_node *rn;
struct f2fs_summary *sum_entry;
- struct page *page, *tmp;
+ struct inode *inode = sbi->sb->s_bdev->bd_inode;
block_t addr;
int bio_blocks = MAX_BIO_BLOCKS(max_hw_blocks(sbi));
- int i, last_offset, nrpages, err = 0;
- LIST_HEAD(page_list);
+ struct page *pages[bio_blocks];
+ int i, idx, last_offset, nrpages, err = 0;
/* scan the node segment */
last_offset = sbi->blocks_per_seg;
@@ -1709,29 +1703,31 @@ int restore_node_summary(struct f2fs_sb_info *sbi,
nrpages = min(last_offset - i, bio_blocks);
/* read ahead node pages */
- nrpages = ra_sum_pages(sbi, _list, addr, nrpages);
+ nrpages = ra_sum_pages(sbi, pages, addr, nrpages);
if (!nrpages)
return -ENOMEM;
- list_for_each_entry_safe(page, tmp, _list, lru) {
+ for (idx = 0; idx < nrpages; idx++) {
if (err)
goto skip;
- lock_page(page);
- if (unlikely(!PageUptodate(page))) {
+ lock_page(pages[idx]);
+ if (unlikely(!PageUptodate(pages[idx]))) {
err = -EIO;
} else {
- rn = F2FS_NODE(page);
+ rn = F2FS_NODE(pages[idx]);
sum_entry->nid = rn->footer.nid;
sum_entry->version = 0;
sum_entry->ofs_in_node = 0;
sum_entry++;
}
- unlock_page(page);
+ unlock_page(pages[idx]);
skip:
- list_del(>lru);
- __free_pages(page, 0);
+
Re: [PATCH 4/9] staging: ion: remove struct ion_page_pool_item
Hello, On 05/26/2014 07:04 PM, Heesub Shin wrote: Now that the order information is held on struct page itself, we do not need to use extra data structure. This commit reduces unnecessary slab usage for allocating small objects. Oops. I need to amend changelog above and resend this patchset. regards, Heesub -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 0/3] arch: unicore32: ksyms: export several implemeted symbols to avoid compiling failure
On 05/27/2014 08:13 AM, 管雪涛 wrote: > - Chen Gang 写道： >> unicore32 has implemented 'find_first_bit', 'find_first_zero_bit', >> 'pm_power_off', and '__cpuc_coherent_kern_range', need export them to >> avoid compiling failure. >> >> The related error (with allmodconfig under unicore32): >> >> MODPOST 4039 modules >> ERROR: "find_first_bit" [sound/soc/codecs/snd-soc-uda1380.ko] undefined! >> ERROR: "find_first_zero_bit" [net/sctp/sctp.ko] undefined! >> [...] >> ERROR: "__cpuc_coherent_kern_range" [drivers/misc/lkdtm.ko] undefined! >> ERROR: "pm_power_off" [drivers/mfd/retu-mfd.ko] undefined! >> [...] >> >> Signed-off-by: Chen Gang > > Thanks, I'm waiting for these patches. > And then, I can request-pull in this month. > Thank you for your work. Hope we can finish within this month. And next month, I shall start another architectures. But I am still very glad to continue to provide contributions for unicore32, and as far as I know: - allmodconfig under unicore32 finds many warnings which I skipped now. (just like allmodconfig under another architectures without '-W') - open source unicore32 qemu still need guys to continue. - open source unicore32 cross-compiler still need guys to continue. If I have chance for them, I shall try (at present, I have started providing contribution to qemu, and just starting for toolchain, and will start for kvm/xen in 3rd or 4th quater 2014). Thanks. -- Chen Gang Open, share, and attitude like air, water, and life which God blessed -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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/8] OF: Introduce DT overlay support.
On Mon, May 26, 2014 at 04:42:44PM -0700, Guenter Roeck wrote: > On 05/26/2014 03:36 PM, Sebastian Reichel wrote: > >On Mon, May 26, 2014 at 10:33:03PM +0100, Grant Likely wrote: > >>After thinking about it more, I think it is very likely that removing > >>all the overlays is the correct thing to do in the kexec use-case. When > >>kexec-ing, it makes sense that we'd want the exact same behaviour from > >>the kexec'ed kernel. That means we want the device drivers to do the > >>same thing including loading whatever overlays they depend on. > >> > >>If the flattened tree was left applied, then the behaviour becomes > >>different. > >> > >>I say always remove the overlays unless explicitly told not to, but I'm > >>struggling to come up with use cases where keeping them applied is > >>desirable. > > > >I would assume, that I want them applied in most cases. DT describes > >the hardware. If I kexec into a new kernel I change software, not > >hardware. > > > >Maybe I'm missing the main purpose of the feature. I currently see > >two useful usecases for DT overlays: > > > >1. The dtb the kernel is booted with cannot be changed for some > >reason, but the board has additional hardware attached (e.g. > >the user added a sensor on the i2c bus) > >2. The hardware is changed on the fly (e.g. the user flashed the > >FPGA part of a zynq processor), sensors on i2c bus, ... > > > >In both cases the kernel should be booted with the additional > >overlay information IMHO. Though for the second case it should > >be possible to remove the "programmed" hardware information > >somehow. > > > > 3. Some hot-plug device or card is inserted or removed. Can you give a more specific example? I guess most hot-plug devices are connected to busses, which are not described via DT, but support auto-identification (USB, PCI, ...) > I would argue that the kernel should _not_ be booted with the > overlay in place. well the device is still attached to the system when you kexec into the new kernel, isn't it? > Otherwise the code handling overlays would have to have special > handling for the restart case, which is much more complex than > just to re-insert the overlay when it is determined that the > device or card is still there. I assume, that the kernel cannot auto-detect the attached hardware. Otherwise we don't need the DT entries, but can simply scan the bus. So the restart case (or restart + kexec case if kexec behaves like a restart) means, that userspace needs to provide the information about device existence. Removing the overlay is like dropping information supplied from the user. Not something, which should be done carelessly. -- Sebastian signature.asc Description: Digital signature
RE: [PATCH] KVM: lapic: sync highest ISR to hardware apic on EOI
Paolo Bonzini wrote on 2014-05-26:
> Il 26/05/2014 05:44, Zhang, Yang Z ha scritto:
>> Paolo Bonzini wrote on 2014-05-23:
>>> When Hyper-V enlightenments are in effect, Windows prefers to issue
>>> an Hyper-V MSR write to issue an EOI rather than an x2apic MSR write.
>>> The Hyper-V MSR write is not handled by the processor, and besides
>>> being slower, this also causes bugs with APIC virtualization. The
>>> reason is that on EOI the processor will modify the highest
>>> in-service interrupt (SVI) field of the VMCS, as explained in
>>> section
>>> 29.1.4 of the SDM.
>>>
>>
>> Not only SVI update. It also includes ISR and PPR update. During PPR
>> update, a new pending interrupt may be recognized and inject to guest.
>
> Right, but SVI update is the only part that is missing. Writing VISR
> is done by apic_clear_isr and PPR virtualization is done by
> apic_update_ppr. PPR virtualization is also done anyway at any VM
> entry, together with evaluating and delivering pending virtual interrupts.
>
> We'll do two PPR virtualizations (one in KVM, one in the processor),
> but that's ok because they're idempotent.
>
> We also operate as if the EOI exit bitmap was all ones, but that's ok
> because a useless kvm_ioapic_send_eoi is not harmful.
>
>>> static inline void apic_clear_isr(int vec, struct kvm_lapic *apic)
>>> {
>>> - if (__apic_test_and_clear_vector(vec, apic->regs + APIC_ISR))
>>> + struct kvm_vcpu *vcpu;
>>> + if (!__apic_test_and_clear_vector(vec, apic->regs + APIC_ISR))
>>> + return;
>>> +
>>> + vcpu = apic->vcpu;
>>> +
>>> + /*
>>> +* We do get here for APIC virtualization enabled if the guest
>>> +* uses the Hyper-V APIC enlightenment. In this case we may need
>>> +* to trigger a new interrupt delivery by writing the SVI field;
>>> +* on the other hand isr_count and highest_isr_cache are unused
>>> +* and must be left alone.
>>> +*/
>>> + if (unlikely(kvm_apic_vid_enabled(vcpu->kvm)))
>>> + kvm_x86_ops->hwapic_isr_update(vcpu->kvm,
>>> + apic_find_highest_isr(apic));
>>
>> If there is a pending interrupt, will it be recognized? I am not
>> looking into the Hyper-V enlightenments code, not sure whether it
>> already covers interrupt recognition. But if it doesn't do it, then
>> we need to do it.
>
> Yes, on the next VM entry the processor will do RVI to the PPR.
> Before the VM entry KVM_REQ_EVENT will also be processed, which
> updates RVI in hwapic_irr_update .
Ok, thanks for explanation.
Reviewed-by: Yang Zhang
>
> Paolo
Best regards,
Yang
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 3.14: WARNING: sysfs group ffffffff81c50ca0 not found for kobject 'target5:0:0'
Hi Olaf, On 16.05.2014 19:18, Olaf Hering wrote: I did unplug an USB stick by accident with 3.14.4, the result is this warning: [94414.233882] usb 1-3: USB disconnect, device number 4 [94414.245377] scsi 5:0:0:0: rejecting I/O to offline device [94414.245383] scsi 5:0:0:0: killing request [94414.370354] FAT-fs (sdc1): unable to read boot sector to mark fs as dirty [94414.370393] [ cut here ] [94414.370400] WARNING: CPU: 2 PID: 3619 at fs/sysfs/group.c:216 sysfs_remove_group+0xa1/0xb0() [94414.370403] sysfs group 81c50ca0 not found for kobject 'target5:0:0' This [1] might fix the problem you encountered. I reckon one of your drivers exposes a binary attribute file in a named attribute group, which it tries to remove when being unloaded. However, the path it looks for this attribute file is likely wrong. [1] http://comments.gmane.org/gmane.linux.kernel/1684070 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V3 4/8] driver/core: cpu: initialize opp table
On 27 May 2014 05:34, Viresh Kumar wrote: > We are also using it for cpu->dev_id, but that's not so important. This > routine wouldn't have existed if you wouldn't have asked for it. It is > just a wrapper over of_init_opp_table, which also has a dummy > implementation when its not supported. > > So, it might not be worth enough for any other code to use it. :) > And so I added it here. > > Let me know how/where do you want it and I will resend it quickly. There is another option here, add these print messages in of_init_opp_table() ? That's the only difference new wrapper has. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
回复： [PATCH 3/3] arch: unicore32: ksyms: export '__cpuc_coherent_kern_range' to avoid compiling failure
- Chen Gang 写道： > flush_icache_range() is '__cpuc_coherent_kern_range' under unicore32, > and lkdtm.ko needs it. At present, '__cpuc_coherent_kern_range' is > still used by unicore32, so export it to avoid compiling failure. > > The related error (with allmodconfig under unicore32): > > ERROR: "__cpuc_coherent_kern_range" [drivers/misc/lkdtm.ko] undefined! > > > Signed-off-by: Chen Gang Acked-by: Xuetao Guan > --- > arch/unicore32/mm/proc-syms.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/arch/unicore32/mm/proc-syms.c b/arch/unicore32/mm/proc-syms.c > index f30071e..21c00fc 100644 > --- a/arch/unicore32/mm/proc-syms.c > +++ b/arch/unicore32/mm/proc-syms.c > @@ -19,5 +19,7 @@ > EXPORT_SYMBOL(cpu_dcache_clean_area); > EXPORT_SYMBOL(cpu_set_pte); > > +EXPORT_SYMBOL(__cpuc_coherent_kern_range); > + > EXPORT_SYMBOL(__cpuc_dma_flush_range); > EXPORT_SYMBOL(__cpuc_dma_clean_range); > -- > 1.9.2.459.g68773ac -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
回复： [PATCH 2/3] arch: unicore32: ksyms: export 'pm_power_off' to avoid compiling failure.
- Chen Gang 写道：
> Two driver modules need 'pm_power_off', so export it.
>
> The related error (with allmodconfig under unicore32):
>
> MODPOST 4039 modules
> ERROR: "pm_power_off" [drivers/mfd/retu-mfd.ko] undefined!
> ERROR: "pm_power_off" [drivers/char/ipmi/ipmi_poweroff.ko] undefined!
>
>
> Signed-off-by: Chen Gang
Acked-by: Xuetao Guan
> ---
> arch/unicore32/kernel/process.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/unicore32/kernel/process.c b/arch/unicore32/kernel/process.c
> index 778ebba..b008e99 100644
> --- a/arch/unicore32/kernel/process.c
> +++ b/arch/unicore32/kernel/process.c
> @@ -60,6 +60,7 @@ void machine_halt(void)
> * Function pointers to optional machine specific functions
> */
> void (*pm_power_off)(void) = NULL;
> +EXPORT_SYMBOL(pm_power_off);
>
> void machine_power_off(void)
> {
> --
> 1.9.2.459.g68773ac
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/3] arch: unicore32: ksyms: export additional find_first_*() to avoid compiling failure
- Chen Gang 写道： > Some modules need find_first_bit() and find_first_zero_bit(), so export > them. > > The related error (with allmodconfig under unicore32): > > MODPOST 4039 modules > ERROR: "find_first_bit" [sound/soc/codecs/snd-soc-uda1380.ko] undefined! > ERROR: "find_first_zero_bit" [net/sctp/sctp.ko] undefined! > ... > > > Signed-off-by: Chen Gang Acked-by: Xuetao Guan > --- > arch/unicore32/kernel/ksyms.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/arch/unicore32/kernel/ksyms.c b/arch/unicore32/kernel/ksyms.c > index e78911a..0323528 100644 > --- a/arch/unicore32/kernel/ksyms.c > +++ b/arch/unicore32/kernel/ksyms.c > @@ -23,6 +23,8 @@ > > #include "ksyms.h" > > +EXPORT_SYMBOL(find_first_bit); > +EXPORT_SYMBOL(find_first_zero_bit); > EXPORT_SYMBOL(find_next_zero_bit); > EXPORT_SYMBOL(find_next_bit); > > -- > 1.9.2.459.g68773ac -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
回复： [PATCH 0/3] arch: unicore32: ksyms: export several implemeted symbols to avoid compiling failure
- Chen Gang 写道： > unicore32 has implemented 'find_first_bit', 'find_first_zero_bit', > 'pm_power_off', and '__cpuc_coherent_kern_range', need export them to > avoid compiling failure. > > The related error (with allmodconfig under unicore32): > > MODPOST 4039 modules > ERROR: "find_first_bit" [sound/soc/codecs/snd-soc-uda1380.ko] undefined! > ERROR: "find_first_zero_bit" [net/sctp/sctp.ko] undefined! > [...] > ERROR: "__cpuc_coherent_kern_range" [drivers/misc/lkdtm.ko] undefined! > ERROR: "pm_power_off" [drivers/mfd/retu-mfd.ko] undefined! > [...] > > Signed-off-by: Chen Gang Thanks, I'm waiting for these patches. And then, I can request-pull in this month. Xuetao > --- > arch/unicore32/kernel/ksyms.c | 2 ++ > arch/unicore32/kernel/process.c | 1 + > arch/unicore32/mm/proc-syms.c | 2 ++ > 3 files changed, 5 insertions(+) > > > Thanks. > -- > Chen Gang > > Open, share, and attitude like air, water, and life which God blessed -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/3] arch: unicore32: ksyms: export '__cpuc_coherent_kern_range' to avoid compiling failure
flush_icache_range() is '__cpuc_coherent_kern_range' under unicore32, and lkdtm.ko needs it. At present, '__cpuc_coherent_kern_range' is still used by unicore32, so export it to avoid compiling failure. The related error (with allmodconfig under unicore32): ERROR: "__cpuc_coherent_kern_range" [drivers/misc/lkdtm.ko] undefined! Signed-off-by: Chen Gang --- arch/unicore32/mm/proc-syms.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/unicore32/mm/proc-syms.c b/arch/unicore32/mm/proc-syms.c index f30071e..21c00fc 100644 --- a/arch/unicore32/mm/proc-syms.c +++ b/arch/unicore32/mm/proc-syms.c @@ -19,5 +19,7 @@ EXPORT_SYMBOL(cpu_dcache_clean_area); EXPORT_SYMBOL(cpu_set_pte); +EXPORT_SYMBOL(__cpuc_coherent_kern_range); + EXPORT_SYMBOL(__cpuc_dma_flush_range); EXPORT_SYMBOL(__cpuc_dma_clean_range); -- 1.9.2.459.g68773ac -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/4] staging: dgap: implement proper error handling in dgap_firmware_load()
Hi, Dan
2014-05-26 19:50 GMT+09:00 Dan Carpenter :
> On Mon, May 26, 2014 at 07:23:47PM +0900, Daeseok Youn wrote:
>> When dgap_tty_init() and dgap_tty_register_ports() are failed,
>> these are needed to free some memory properly.
>>
>> It can be handled by calling dgap_tty_uninit() and dgap_cleanup_board().
>> But tty's ports are not registered yet when these function are failed,
>> so brd->nasync set to zero.
>>
>> Signed-off-by: Daeseok Youn
>> ---
>> drivers/staging/dgap/dgap.c | 21 -
>> 1 files changed, 16 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/staging/dgap/dgap.c b/drivers/staging/dgap/dgap.c
>> index 60b7d70..db24f70 100644
>> --- a/drivers/staging/dgap/dgap.c
>> +++ b/drivers/staging/dgap/dgap.c
>> @@ -954,19 +954,30 @@ static int dgap_firmware_load(struct pci_dev *pdev,
>> int card_type)
>>* Do tty device initialization.
>>*/
>> ret = dgap_tty_init(brd);
>> - if (ret < 0) {
>> - dgap_tty_uninit(brd);
>> - return ret;
>> - }
>> + if (ret < 0)
>> + goto err_cleanup;
>>
>> ret = dgap_tty_register_ports(brd);
>> if (ret)
>> - return ret;
>> + goto err_cleanup;
>>
>> brd->state = BOARD_READY;
>> brd->dpastatus = BD_RUNNING;
>>
>> return 0;
>> +
>> +err_cleanup:
>> + /*
>> + * Clear nasync to zero for avoiding to call
>> + * some destroyer for tty's ports which are not
>> + * registered yet in dgap_tty_uninit().
>> + */
>> + brd->nasync = 0;
>> +
>> + dgap_tty_uninit(brd);
>> + dgap_cleanup_board(brd);
>> + return ret;
>
> Wow. This is nasty. We shouldn't have to call dgap_tty_uninit() when
> the init failed. Can't we clean this up instead of adding
> "brd->nasync = 0;" work arounds?
I think dgap_tty_uninit() should be called when the init failed. It
need to unregister
serial and printer driver and free them.
And I will try to clean this up without that workaround.
Thanks for review.
regards,
Daeseok Youn
>
> regards,
> dan carpenter
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/3] arch: unicore32: ksyms: export 'pm_power_off' to avoid compiling failure.
Two driver modules need 'pm_power_off', so export it.
The related error (with allmodconfig under unicore32):
MODPOST 4039 modules
ERROR: "pm_power_off" [drivers/mfd/retu-mfd.ko] undefined!
ERROR: "pm_power_off" [drivers/char/ipmi/ipmi_poweroff.ko] undefined!
Signed-off-by: Chen Gang
---
arch/unicore32/kernel/process.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/unicore32/kernel/process.c b/arch/unicore32/kernel/process.c
index 778ebba..b008e99 100644
--- a/arch/unicore32/kernel/process.c
+++ b/arch/unicore32/kernel/process.c
@@ -60,6 +60,7 @@ void machine_halt(void)
* Function pointers to optional machine specific functions
*/
void (*pm_power_off)(void) = NULL;
+EXPORT_SYMBOL(pm_power_off);
void machine_power_off(void)
{
--
1.9.2.459.g68773ac
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V3 4/8] driver/core: cpu: initialize opp table
On 27 May 2014 05:02, Rafael J. Wysocki wrote: > Do you actually use cpu anywere in this function for anything other than > just accessing cpu->dev? If not, why not to pass cpu->dev to it and > move it somewhere in the OPP core? We are also using it for cpu->dev_id, but that's not so important. This routine wouldn't have existed if you wouldn't have asked for it. It is just a wrapper over of_init_opp_table, which also has a dummy implementation when its not supported. So, it might not be worth enough for any other code to use it. :) And so I added it here. Let me know how/where do you want it and I will resend it quickly. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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/3] arch: unicore32: ksyms: export additional find_first_*() to avoid compiling failure
Some modules need find_first_bit() and find_first_zero_bit(), so export them. The related error (with allmodconfig under unicore32): MODPOST 4039 modules ERROR: "find_first_bit" [sound/soc/codecs/snd-soc-uda1380.ko] undefined! ERROR: "find_first_zero_bit" [net/sctp/sctp.ko] undefined! ... Signed-off-by: Chen Gang --- arch/unicore32/kernel/ksyms.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/unicore32/kernel/ksyms.c b/arch/unicore32/kernel/ksyms.c index e78911a..0323528 100644 --- a/arch/unicore32/kernel/ksyms.c +++ b/arch/unicore32/kernel/ksyms.c @@ -23,6 +23,8 @@ #include "ksyms.h" +EXPORT_SYMBOL(find_first_bit); +EXPORT_SYMBOL(find_first_zero_bit); EXPORT_SYMBOL(find_next_zero_bit); EXPORT_SYMBOL(find_next_bit); -- 1.9.2.459.g68773ac -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] drm/nouveau: disable caching for VRAM BOs on ARM
On Mon, May 26, 2014 at 6:21 PM, Lucas Stach wrote: > Am Montag, den 26.05.2014, 09:45 +0300 schrieb Terje Bergström: >> On 23.05.2014 17:40, Alex Courbot wrote: >> > On 05/23/2014 06:59 PM, Lucas Stach wrote: >> > So after checking with more knowledgeable people, it turns out this is >> > the expected behavior on ARM and BAR regions should be mapped uncached >> > on GK20A. All the more reasons to avoid using the BAR at all. >> >> This is actually specific to Tegra. >> >> >> You may want to make yourself aware of all the quirks required for >> >> sharing memory between the GPU and CPU on an ARM host. I think there are >> >> far more involved than what you see now and writing an replacement for >> >> TTM will not be an easy task. >> >> >> >> Doing away with the concept of two memory areas will not get you to a >> >> single unified address space. You would have to deal with things like >> >> not being able to change the caching state of pages in the systems >> >> lowmem yourself. You will still have to deal with remapping pages that >> >> aren't currently visible to the CPU (ok this is not an issue on Jetson >> >> right now as it only has 2GB of RAM), because it's in systems highmem, >> >> or even in a different LPAE area. >> >> >> >> You really want to be sure you are aware of all the consequences of >> >> this, before considering this task. >> > >> > Yep, that's why I am seeking advice here. My first hope is that with a >> > few tweaks we will be able to keep using TTM and the current nouveau_bo >> > implementation. But unless I missed something this is not going to be easy. >> > >> > We can also use something like the patch I originally sent to make it >> > work, although not with good performance, on GK20A. Not very graceful, >> > but it will allow applications to run. >> > >> > In the long run though, we will want to achieve better performance, and >> > it seems like a BO implementation targeted at UMA devices would also be >> > beneficial to quite a few desktop GPUs. So as tricky as it may be I'm >> > interested in gathering thoughts and why not giving it a first try with >> > GK20A, even if it imposes some limitations like having buffers in lowmem >> > in a first time (we can probably live with this one for a short while, >> > and 64 bits will also be coming to the rescue :)) >> >> I don't think lowmem or LPAE is any problem, if the memory manager is >> designed with that in mind. Vast majority of the buffers kernel >> allocates do not need to be touched in kernel space. >> >> Actually I can't think of any buffers that we allocate on behalf of user >> space that would need to be permanently mapped also to kernel. In case >> or relocs only push buffer needs to be temporarily mapped to kernel. >> >> Ultimately even relocs are not necessary if we expose GPU virtual >> addresses directly to user space. But that's another topic. >> > Nouveau already exposes constant virtual addresses to userspace and > skips the pushbuf patching when the presumed offset from userspace is > the same as what the kernel thinks it should be. > > The problem with lowmem on ARM is that you can't unmap those pages from > the kernel cached mapping. So if you alloc a page, give it to userspace > and userspace decides to map the page WC you just produced a conflicting > mapping, which may yield undefined results on ARMv7. You may think this > is not a problem as you are not touching the kernel cached mapping, but > in fact it is. The CPUs prefetcher can still access this mapping. Why would this memory be mapped into the kernel? AFAICT Nouveau only maps fences and (somehow) PBs into the kernel. Other BOs are not mapped unless I missed something. Or are you talking about VRAM allocated by dma_alloc_*()? We prevent this from happening by using the CMA allocator (which doesn't create a kmap) directly, which has its own problems (cannot compile Nouveau as a module and use these allocators). In the future we plan to use the iommu to present sparse memory pages in a way the GPU likes. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/3] arch: unicore32: ksyms: export several implemeted symbols to avoid compiling failure
unicore32 has implemented 'find_first_bit', 'find_first_zero_bit', 'pm_power_off', and '__cpuc_coherent_kern_range', need export them to avoid compiling failure. The related error (with allmodconfig under unicore32): MODPOST 4039 modules ERROR: "find_first_bit" [sound/soc/codecs/snd-soc-uda1380.ko] undefined! ERROR: "find_first_zero_bit" [net/sctp/sctp.ko] undefined! [...] ERROR: "__cpuc_coherent_kern_range" [drivers/misc/lkdtm.ko] undefined! ERROR: "pm_power_off" [drivers/mfd/retu-mfd.ko] undefined! [...] Signed-off-by: Chen Gang --- arch/unicore32/kernel/ksyms.c | 2 ++ arch/unicore32/kernel/process.c | 1 + arch/unicore32/mm/proc-syms.c | 2 ++ 3 files changed, 5 insertions(+) Thanks. -- Chen Gang Open, share, and attitude like air, water, and life which God blessed -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: linux-next: build failure after merge of the l2-mtd tree
Hi Brian, On Mon, 26 May 2014 10:42:25 -0700 Brian Norris wrote: > > On Thu, May 22, 2014 at 03:30:47PM +1000, Stephen Rothwell wrote: > > Hi Artem, > > FYI, I'm managing this tree now, not Artem. OK, noted. Is there a different URL for the tree as well? Currently it is git://git.infradead.org/users/dedekind/l2-mtd-2.6.git#master . Here is the legalese: Thanks for adding your subsystem tree as a participant of linux-next. As you may know, this is not a judgment of your code. The purpose of linux-next is for integration testing and to lower the impact of conflicts between subsystems in the next merge window. You will need to ensure that the patches/commits in your tree/series have been: * submitted under GPL v2 (or later) and include the Contributor's Signed-off-by, * posted to the relevant mailing list, * reviewed by you (or another maintainer of your subsystem tree), * successfully unit tested, and * destined for the current or next Linux merge window. Basically, this should be just what you would send to Linus (or ask him to fetch). It is allowed to be rebased if you deem it necessary. -- Cheers, Stephen Rothwell s...@canb.auug.org.au signature.asc Description: PGP signature
Re: [PATCH V4 1/3] cpufreq: handle calls to ->target_index() in separate routine
On 27 May 2014 04:51, Rafael J. Wysocki wrote: > I guess I can take this one without the rest of the series? Yes. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] [media] usbtv: fix leak at failure path in usbtv_probe()
On Sat, 2014-05-24 at 00:47 +0400, Alexey Khoroshilov wrote: > Error handling code in usbtv_probe() misses usb_put_dev(). > > Found by Linux Driver Verification project (linuxtesting.org). > > Signed-off-by: Alexey Khoroshilov Acked-by: Lubomir Rintel Thank you! Lubo > --- > drivers/media/usb/usbtv/usbtv-core.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/drivers/media/usb/usbtv/usbtv-core.c > b/drivers/media/usb/usbtv/usbtv-core.c > index 2f87ddfa469f..473fab81b602 100644 > --- a/drivers/media/usb/usbtv/usbtv-core.c > +++ b/drivers/media/usb/usbtv/usbtv-core.c > @@ -91,6 +91,8 @@ static int usbtv_probe(struct usb_interface *intf, > return 0; > > usbtv_video_fail: > + usb_set_intfdata(intf, NULL); > + usb_put_dev(usbtv->udev); > kfree(usbtv); > > return ret; -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 2/2] watchdog: Remove drivers for W83697HF and W83697UG
On 05/26/2014 02:26 PM, Wim Van Sebroeck wrote: Hi Guenter, Since both chips are now supported by the w83627hf watchdog driver, the chip specific drivers are no longer needed and can be removed. Signed-off-by: Guenter Roeck --- v3: rebase to latest upstream kernel v2: resend, no change to v1 drivers/watchdog/Kconfig| 30 --- drivers/watchdog/Makefile |2 - drivers/watchdog/w83697hf_wdt.c | 460 --- drivers/watchdog/w83697ug_wdt.c | 397 - 4 files changed, 889 deletions(-) delete mode 100644 drivers/watchdog/w83697hf_wdt.c delete mode 100644 drivers/watchdog/w83697ug_wdt.c Has been added to linux-watchdog-next. 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: [PATCH v4 2/8] OF: Introduce DT overlay support.
On 05/26/2014 02:44 PM, Geert Uytterhoeven wrote: Hi Grant, On Mon, May 26, 2014 at 11:33 PM, Grant Likely wrote: After thinking about it more, I think it is very likely that removing all the overlays is the correct thing to do in the kexec use-case. When kexec-ing, it makes sense that we'd want the exact same behaviour from the kexec'ed kernel. That means we want the device drivers to do the same thing including loading whatever overlays they depend on. Are the device drivers loading the overlays? That sounds a bit backwards to me. Depends on what you mean with 'device driver'. In our case we have a driver dedicated to handle card status. Quite similar to what the connector subsystem does but with significantly more functionality (including devicetree overlay management). 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 v4 2/8] OF: Introduce DT overlay support.
On 05/26/2014 03:36 PM, Sebastian Reichel wrote: Hi, On Mon, May 26, 2014 at 10:33:03PM +0100, Grant Likely wrote: After thinking about it more, I think it is very likely that removing all the overlays is the correct thing to do in the kexec use-case. When kexec-ing, it makes sense that we'd want the exact same behaviour from the kexec'ed kernel. That means we want the device drivers to do the same thing including loading whatever overlays they depend on. If the flattened tree was left applied, then the behaviour becomes different. I say always remove the overlays unless explicitly told not to, but I'm struggling to come up with use cases where keeping them applied is desirable. I would assume, that I want them applied in most cases. DT describes the hardware. If I kexec into a new kernel I change software, not hardware. Maybe I'm missing the main purpose of the feature. I currently see two useful usecases for DT overlays: 1. The dtb the kernel is booted with cannot be changed for some reason, but the board has additional hardware attached (e.g. the user added a sensor on the i2c bus) 2. The hardware is changed on the fly (e.g. the user flashed the FPGA part of a zynq processor), sensors on i2c bus, ... In both cases the kernel should be booted with the additional overlay information IMHO. Though for the second case it should be possible to remove the "programmed" hardware information somehow. 3. Some hot-plug device or card is inserted or removed. I would argue that the kernel should _not_ be booted with the overlay in place. Otherwise the code handling overlays would have to have special handling for the restart case, which is much more complex than just to re-insert the overlay when it is determined that the device or card is still there. 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/
