[PATCH] extcon: fix switch class porting guide (Documentation)

[MyungJoo Ham]

- Unfinished sentence finished.
- Incorrect description on the compat-mode condition corrected.

Signed-off-by: MyungJoo Ham 
---
 Documentation/extcon/porting-android-switch-class |9 +++--
 1 files changed, 3 insertions(+), 6 deletions(-)

diff --git a/Documentation/extcon/porting-android-switch-class 
b/Documentation/extcon/porting-android-switch-class
index eb0fa5f..ec5f92d 100644
--- a/Documentation/extcon/porting-android-switch-class
+++ b/Documentation/extcon/porting-android-switch-class
@@ -48,7 +48,7 @@ so that they are still compatible with legacy userspace 
processes.
Extcon's extended features for switch device drivers with
complex features usually required magic numbers in state
value of switch_dev. With extcon, such magic numbers that
-   support multiple cables (
+   support multiple cables are no more required or supported.
 
   1. Define cable names at edev->supported_cable.
   2. (Recommended) remove print_state callback.
@@ -112,11 +112,8 @@ exclusive, the two cables cannot be in ATTACHED state 
simulteneously.
 
 ** ABI Location
 
-  If "CONFIG_ANDROID" is enabled and "CONFIG_ANDROID_SWITCH" is
-disabled, /sys/class/switch/* are created as symbolic links to
-/sys/class/extcon/*. Because CONFIG_ANDROID_SWITCH creates
-/sys/class/switch directory, we disable symboling linking if
-CONFIG_ANDROID_SWITCH is enabled.
+  If "CONFIG_ANDROID" is enabled, /sys/class/switch/* are created
+as symbolic links to /sys/class/extcon/*.
 
   The two files of switch class, name and state, are provided with
 extcon, too. When the multistate support (STEP 2 of CHAPTER 1.) is
-- 
1.7.5.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] extcon: gpio: Request gpio pin before modifying its state

[Chanwoo Choi]

Hi Guenter,

On 11/23/2013 02:26 AM, Guenter Roeck wrote:
> Commit 338de0ca (extcon: gpio: Use gpio driver/chip debounce if supported)
> introduced a call to gpio_set_debounce() before actually requesting the
> respective gpio pin from the gpio subsystem.
> 
> The gpio subsystem expects that a gpio pin was requested before modifying its
> state. Not doing so results in a warning from gpiolib, and the gpio pin is
> auto-requested. This in turn causes the subsequent devm_gpio_request_one()
> to fail. So devm_gpio_request_one() must be called prior to calling
> gpio_set_debounce().
> 
> Signed-off-by: Guenter Roeck 
> ---
>  drivers/extcon/extcon-gpio.c |   11 ++-
>  1 file changed, 6 insertions(+), 5 deletions(-)
> 

Applid it on extcon-next branch.

Thanks,
Chanwoo Choi

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 2/6] net: MOXA ART: connect to PHY

[Florian Fainelli]

Le lundi 25 novembre 2013, 16:27:04 Jonas Jensen a écrit :
> The kernel now has a MDIO bus driver and a phy_driver (RTL8201CP),
> connect to this PHY using OF.
> 
> Signed-off-by: Jonas Jensen 

Looks good:

Reviewed-by: Florian Fainelli 

> ---
> 
> Notes:
> Thanks for reviewing!
> 
> Changes since v1:
> 
> 1. split ethtool support to separate patch
> 2. changes to devicetree binding document
> 3. add moxart_mac_update_duplex()
> 4. compare previous link state/speed/duplex on link adjust
> 5. use of_get_phy_mode() not PHY_INTERFACE_MODE_MII
> 6. bail on of_parse_phandle() failure
> 7. remove "if (!priv->phy_dev) return -ENODEV;"
>moxart_do_ioctl()
> 8. remove "if (priv->phy_dev)"
>moxart_mac_open(), moxart_mac_stop()
> 
> Applies to next-20131125
> 
>  .../devicetree/bindings/net/moxa,moxart-mac.txt| 47 ++-
>  drivers/net/ethernet/moxa/moxart_ether.c   | 92
> +- drivers/net/ethernet/moxa/moxart_ether.h   |
>  2 +
>  3 files changed, 138 insertions(+), 3 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/net/moxa,moxart-mac.txt
> b/Documentation/devicetree/bindings/net/moxa,moxart-mac.txt index
> 583418b..56f0374 100644
> --- a/Documentation/devicetree/bindings/net/moxa,moxart-mac.txt
> +++ b/Documentation/devicetree/bindings/net/moxa,moxart-mac.txt
> @@ -1,21 +1,64 @@
>  MOXA ART Ethernet Controller
> 
> +Integrated MDIO bus node:
> +
> +- compatible: "moxa,moxart-mdio"
> +- Inherets from MDIO bus node binding[1]
> +
> +[1] Documentation/devicetree/bindings/net/phy.txt
> +
> +
> +Ethernet node:
> +
>  Required properties:
> 
>  - compatible : Must be "moxa,moxart-mac"
>  - reg : Should contain register location and length
>  - interrupts : Should contain the mac interrupt number
> 
> +Optional Properties:
> +
> +- phy-handle : the phandle to a PHY node
> +
> +
>  Example:
> 
> + mdio0: mdio@90900090 {
> + compatible = "moxa,moxart-mdio";
> + reg = <0x90900090 0x8>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + ethphy0: ethernet-phy@1 {
> + device_type = "ethernet-phy";
> + compatible = "moxa,moxart-rtl8201cp", 
> "ethernet-phy-ieee802.3-c22";
> + reg = <1>;
> + };
> + };
> +
> + mdio1: mdio@9290 {
> + compatible = "moxa,moxart-mdio";
> + reg = <0x9290 0x8>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + ethphy1: ethernet-phy@1 {
> + device_type = "ethernet-phy";
> + compatible = "moxa,moxart-rtl8201cp", 
> "ethernet-phy-ieee802.3-c22";
> + reg = <1>;
> + };
> + };
> +
>   mac0: mac@9090 {
>   compatible = "moxa,moxart-mac";
> - reg =   <0x9090 0x100>;
> + reg = <0x9090 0x90>;
>   interrupts = <25 0>;
> + phy-handle = <>;
>   };
> 
>   mac1: mac@9200 {
>   compatible = "moxa,moxart-mac";
> - reg =   <0x9200 0x100>;
> + reg = <0x9200 0x90>;
>   interrupts = <27 0>;
> + phy-handle = <>;
>   };
> diff --git a/drivers/net/ethernet/moxa/moxart_ether.c
> b/drivers/net/ethernet/moxa/moxart_ether.c index 3c14afd..1b87034 100644
> --- a/drivers/net/ethernet/moxa/moxart_ether.c
> +++ b/drivers/net/ethernet/moxa/moxart_ether.c
> @@ -26,6 +26,9 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 
> +#include 
> 
>  #include "moxart_ether.h"
> 
> @@ -61,6 +64,16 @@ static int moxart_set_mac_address(struct net_device
> *ndev, void *addr) return 0;
>  }
> 
> +static int moxart_do_ioctl(struct net_device *ndev, struct ifreq *ir, int
> cmd) +{
> + struct moxart_mac_priv_t *priv = netdev_priv(ndev);
> +
> + if (!netif_running(ndev))
> + return -EINVAL;
> +
> + return phy_mii_ioctl(priv->phy_dev, ir, cmd);
> +}
> +
>  static void moxart_mac_free_memory(struct net_device *ndev)
>  {
>   struct moxart_mac_priv_t *priv = netdev_priv(ndev);
> @@ -110,6 +123,19 @@ static void moxart_mac_enable(struct net_device *ndev)
>  

[PATCH] crypto/caam/jr.c: include linux/of_address.h

[shh.xie]

From: Shaohui Xie 

to avoid a compile error:

drivers/crypto/caam/jr.c: In function 'caam_jr_probe':
drivers/crypto/caam/jr.c:468:2: error: implicit declaration of function
'of_iomap' [-Werror=implicit-function-declaration]
drivers/crypto/caam/jr.c:468:7: warning: assignment makes pointer from
integer without a cast [enabled by default]

Signed-off-by: Shaohui Xie 
---
 drivers/crypto/caam/jr.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/crypto/caam/jr.c b/drivers/crypto/caam/jr.c
index d23356d2..1d80bd3 100644
--- a/drivers/crypto/caam/jr.c
+++ b/drivers/crypto/caam/jr.c
@@ -6,6 +6,7 @@
  */
 
 #include 
+#include 
 
 #include "compat.h"
 #include "regs.h"
-- 
1.8.4.1


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [f2fs-dev][PATCH V2 0/6] f2fs: Enable f2fs support inline data

[Jaegeuk Kim]

Hi Huajun,

Please adjust the following bug fixes in your patches.

---
 fs/f2fs/data.c   |  2 +-
 fs/f2fs/file.c   | 12 +++-
 fs/f2fs/inline.c | 19 +++
 3 files changed, 19 insertions(+), 14 deletions(-)

diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
index 2eed6e3..e44f0ba 100644
--- a/fs/f2fs/data.c
+++ b/fs/f2fs/data.c
@@ -534,8 +534,8 @@ static int get_data_block_ro(struct inode *inode,
sector_t iblock,
 
 static int f2fs_read_data_page(struct file *file, struct page *page)
 {
+   struct inode *inode = page->mapping->host;
int ret;
-   struct inode *inode = file->f_mapping->host;

>> The file pointer is NULL if this page contains file's symlink data,
which induces NULL pointer error.
 
/* If the file has inline data, try to read it directlly */
if (f2fs_has_inline_data(inode))
diff --git a/fs/f2fs/file.c b/fs/f2fs/file.c
index ffafcb9..52bb211 100644
--- a/fs/f2fs/file.c
+++ b/fs/f2fs/file.c
@@ -257,8 +257,7 @@ static int truncate_blocks(struct inode *inode, u64
from)
unsigned int blocksize = inode->i_sb->s_blocksize;
struct dnode_of_data dn;
pgoff_t free_from;
-   int count = 0;
-   int err;
+   int count = 0, err = 0;
 
trace_f2fs_truncate_blocks_enter(inode, from);
 
@@ -266,6 +265,10 @@ static int truncate_blocks(struct inode *inode, u64
from)
((from + blocksize - 1) >> (sbi->log_blocksize));
 
f2fs_lock_op(sbi);
+
+   if (f2fs_has_inline_data(inode))
+   goto done;
+

>> We don't need to do the below actions. Let's skip that.

set_new_dnode(, inode, NULL, NULL, 0);
err = get_dnode_of_data(, free_from, LOOKUP_NODE);
if (err) {
@@ -291,9 +294,8 @@ static int truncate_blocks(struct inode *inode, u64
from)
 
f2fs_put_dnode();
 free_next:
-
-   if (!f2fs_has_inline_data(inode))
-   err = truncate_inode_blocks(inode, free_from);
+   err = truncate_inode_blocks(inode, free_from);
+done:
f2fs_unlock_op(sbi);
 
/* lastly zero out the first data page */
diff --git a/fs/f2fs/inline.c b/fs/f2fs/inline.c
index e9b33d7..6c301cc 100644
--- a/fs/f2fs/inline.c
+++ b/fs/f2fs/inline.c
@@ -48,13 +48,14 @@ int f2fs_read_inline_data(struct inode *inode,
struct page *page)
if (IS_ERR(ipage))
return PTR_ERR(ipage);
 
-   src_addr = inline_data_addr(ipage);
-   dst_addr = page_address(page);
-
zero_user_segment(page, INLINE_DATA_OFFSET,
INLINE_DATA_OFFSET + MAX_INLINE_DATA);
+
/* Copy the whole inline data block */
+   src_addr = inline_data_addr(ipage);
+   dst_addr = kmap(page);
memcpy(dst_addr, src_addr, MAX_INLINE_DATA);
+   kunmap(page);

>> We should do kmap/kunmap for normal data pages.

f2fs_put_page(ipage, 1);
 
SetPageUptodate(page);
@@ -89,12 +90,13 @@ static int __f2fs_convert_inline_data(struct inode
*inode, struct page *page)
return err;
}
 
-   src_addr = inline_data_addr(ipage);
-   dst_addr = page_address(page);
zero_user_segment(page, 0, PAGE_CACHE_SIZE);
 
/* Copy the whole inline data block */
+   src_addr = inline_data_addr(ipage);
+   dst_addr = kmap(page);
memcpy(dst_addr, src_addr, MAX_INLINE_DATA);
+   kunmap(page);

>> ditto.
 
/* write data page to try to make data consistent */
old_blk_addr = dn.data_blkaddr;
@@ -152,12 +154,13 @@ int f2fs_write_inline_data(struct inode *inode,
return err;
ipage = dn.inode_page;
 
-   src_addr = page_address(page);
-   dst_addr = inline_data_addr(ipage);
-
zero_user_segment(ipage, INLINE_DATA_OFFSET,
 INLINE_DATA_OFFSET + MAX_INLINE_DATA);
+
+   src_addr = kmap(page);
+   dst_addr = inline_data_addr(ipage);
memcpy(dst_addr, src_addr, size);
+   kunmap(page);

>> ditto.
 
/* Release the first data block if it is allocated */
if (!f2fs_has_inline_data(inode)) {
-- 
1.8.4.474.g128a96c



-- 
Jaegeuk Kim
Samsung

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[GIT PULL] extcon fixes for 3.13-rc2

[Chanwoo Choi]

Hi Greg,

This is extcon fixes pull request for 3.13-rc2. I add detailed description of
this pull request on below. Please pull extcon fixes with following updates.

The following changes since commit 6ce4eac1f600b34f2f7f58f9cd8f0503d79e42ae:

  Linux 3.13-rc1 (2013-11-22 11:30:55 -0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/extcon.git 
tags/extcon-linus-for-3.13-rc2

for you to fetch changes up to 7585ca0dc950583be7fc62099ca43a0c9551a875:

  extcon: remove freed groups caused the panic or warning in unregister flow 
(2013-11-26 15:17:23 +0900)


Update extcon for 3.13-rc2

This patchset fix NULL pointer error of extcon-arizona driver and fix issue
about memory of device groups when calling extcon_dev_unregister function.


Charles Keepax (1):
  extcon: arizona: Get pdata from arizona structure not device

Wang, Xiaoming (1):
  extcon: remove freed groups caused the panic or warning in unregister flow

 drivers/extcon/extcon-arizona.c | 4 +---
 drivers/extcon/extcon-class.c   | 3 ++-
 2 files changed, 3 insertions(+), 4 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] x86: boot: Fix mixed indentation in a20.c

[Borislav Petkov]

On Mon, Nov 25, 2013 at 04:51:59PM -0800, Joe Perches wrote:



> Perhaps you could dial down your humility a bit. Perhaps you'll reread
> and see if it seems humble to you.

So I vivid reader of LKML and I were wondering how you'd react to the
urge from a kernel maintainer to get you to finally drop that senseless
whitespace jerking off and do some real work.

My money was on "he'll come back with a bunch of petty and irrelevant
arguments instead of *actually* listen to a maintainer".

I guess I won. :-)

-- 
Regards/Gruss,
Boris.

Sent from a fat crate under my desk. Formatting is fine.
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH V2] dma: add common of_dma_slave_xlate()

[Lars-Peter Clausen]

On 11/26/2013 02:25 AM, Stephen Warren wrote:
[...]
> +struct dma_chan *of_dma_slave_xlate(struct of_phandle_args *dma_spec,
> + struct of_dma *ofdma)
> +{
> + struct of_dma_slave_xlate_info *info = ofdma->of_dma_data;
> + struct dma_chan *candidate, *chan;
> + int ret;
> +
> +retry:
> + candidate = NULL;
> +
> + /*
> +  * walk the list of channels registered with the current instance and
> +  * find one that is currently unused
> +  */
> + list_for_each_entry(chan, >device->channels, device_node)
> + if (chan->client_count == 0) {
> + candidate = chan;
> + break;
> + }
> +
> + if (!candidate)
> + return NULL;
> +
> + /*
> +  * dma_get_slave_channel will return NULL if we lost a race between
> +  * the lookup and the reservation
> +  */
> + chan = dma_get_slave_channel(candidate);
> + if (!chan)
> + goto retry;

I think it will be better to implement this functionality in the core. This
means we can hold the dma_list_mutex and don't have to do this retry loop
and do not have to peek at the client_count field in non-core code.
Something like dma_get_free_slave_channel(), which would call
private_candidate() followed by dma_chan_get().

> +
> + if (info->post_alloc) {
> + ret = info->post_alloc(chan, dma_spec);

If you need to do something at the end of the function I think it is nicer
to just wrap this function with your own function instead of adding a callback.

- Lars


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/5] mtip32xx: handle arbitrary size bios

[Kent Overstreet]

On Mon, Nov 25, 2013 at 10:10:18PM -0800, Christoph Hellwig wrote:
> On Mon, Nov 25, 2013 at 02:30:30PM -0800, Kent Overstreet wrote:
> > We get a measurable performance increase by handling this in the driver when
> > we're already looping over the biovec, instead of handling it separately in
> > generic_make_request() (or bio_add_page() originally)
> 
> Given that Jens has a patch queue up to convert the driver to blk-mq
> adjusting the blk-mq infrastructure to handle this might be a better
> plan forward..

I mostly wanted the patch in the series as an example conversion -
converting blk-mq is going to take some thought and time to familiarize
myself with the code.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: (ltc-kernel 7837) Re: [BUG] 3.13-rc1 kernel crash when enable all tracepoints

[Masami Hiramatsu]

(2013/11/26 15:33), Masami Hiramatsu wrote:
> (2013/11/26 13:38), Jovi Zhangwei wrote:
>> Hi,
>>
>> I'm not sure this issue already be fixed or not, it can be reproduced
>> permanently.
>>
>> (I didn't use git-bisect yet, you guys might can understand it quickly)
>>
>> #echo 1 > /sys/kernel/debug/tracing/events/enable
> 
> Thanks for reporting. I could reproduce it.
> 
> To narrow this down, I tried to run the below command
> 
> [tracing]# for i in events/*/*/enable ; do echo $i; echo 1 > $i; done
> 
> And it ran through the end without any problem.
> Hm, next I checked the difference of available_events and set_event.
> 
> [tracing]# diff available_events set_event
> 283d282
> < ftrace:function
> 
> So, I guess it was caused by enabling ftrace:function, and
> it is unable to do that via set_event, nor events/ftrace/enable
> I'm not sure how, but it seems that ftrace:function can be
> enabled by the events/enable.

Oops, No, forget it. When I added a printk in
ftrace_set_clr_event_nolock(), it didn't happen and ftrace/function
is not enabled.

I'm trying to reproduce it on the latest tip kernel again on KVM,
but not yet reproduced.

Thank you,

-- 
Masami HIRAMATSU
IT Management Research Dept. Linux Technology Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu...@hitachi.com


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] intel_idle: Fixed C6 state on Avoton/Rangeley processors

[Bockholdt Arne]

Corrected the MWAIT flag for C-State C6 on Intel Avoton/Rangeley processors.

Signed-off-by: Arne Bockholdt 
---

diff --git a/drivers/idle/intel_idle.c b/drivers/idle/intel_idle.c
index cbd4e9a..92d1206 100644
--- a/drivers/idle/intel_idle.c
+++ b/drivers/idle/intel_idle.c
@@ -329,7 +329,7 @@ static struct cpuidle_state atom_cstates[] __initdata = {
{
.enter = NULL }
 };
-static struct cpuidle_state avn_cstates[CPUIDLE_STATE_MAX] = {
+static struct cpuidle_state avn_cstates[] __initdata = {
{
.name = "C1-AVN",
.desc = "MWAIT 0x00",
@@ -340,7 +340,7 @@ static struct cpuidle_state avn_cstates[CPUIDLE_STATE_MAX] 
= {
{
.name = "C6-AVN",
.desc = "MWAIT 0x51",
-   .flags = MWAIT2flg(0x58) | CPUIDLE_FLAG_TIME_VALID | 
CPUIDLE_FLAG_TLB_FLUSHED,
+   .flags = MWAIT2flg(0x51) | CPUIDLE_FLAG_TIME_VALID | 
CPUIDLE_FLAG_TLB_FLUSHED,
.exit_latency = 15,
.target_residency = 45,
.enter = _idle },

Re: [PATCH 07/12] memory: davinci-aemif: introduce AEMIF driver

[Sekhar Nori]

On Monday 11 November 2013 10:36 PM, Khoronzhuk, Ivan wrote:
> Add new AEMIF driver for EMIF16 davinci controller. The EMIF16 module
> is intended to provide a glue-less interface to a variety of
> asynchronous memory devices like ASRA M, NOR and NAND memory. A total
> of 256M bytes of any of these memories can be accessed at any given
> time via four chip selects with 64M byte access per chip select.
> 
> Synchronous memories such as DDR1 SD RAM, SDR SDRAM and Mobile SDR
> are not supported.
> 
> See http://www.ti.com/lit/ug/sprugz3a/sprugz3a.pdf
> 
> Signed-off-by: Ivan Khoronzhuk 
> ---
>  drivers/memory/Kconfig |   11 ++
>  drivers/memory/Makefile|1 +
>  drivers/memory/davinci-aemif.c |  415 
> 
>  3 files changed, 427 insertions(+)
>  create mode 100644 drivers/memory/davinci-aemif.c
> 
> diff --git a/drivers/memory/Kconfig b/drivers/memory/Kconfig
> index 29a11db..010e75e 100644
> --- a/drivers/memory/Kconfig
> +++ b/drivers/memory/Kconfig
> @@ -7,6 +7,17 @@ menuconfig MEMORY
> 
>  if MEMORY
> 
> +config TI_DAVINCI_AEMIF
> +   bool "Texas Instruments DaVinci AEMIF driver"

This driver cannot be a module? If not, why not?

> +   depends on (ARCH_DAVINCI || ARCH_KEYSTONE) && OF
> +   help
> + This driver is for the AEMIF module available in Texas Instruments
> + SoCs. AEMIF stands for Asynchronous External Memory Interface and
> + is intended to provide a glue-less interface to a variety of
> + asynchronuous memory devices like ASRAM, NOR and NAND memory. A 
> total
> + of 256M bytes of any of these memories can be accessed at a given
> + time via four chip selects with 64M byte access per chip select.
> +
>  config TI_EMIF
> tristate "Texas Instruments EMIF driver"
> depends on ARCH_OMAP2PLUS
> diff --git a/drivers/memory/Makefile b/drivers/memory/Makefile
> index 969d923..af14126 100644
> --- a/drivers/memory/Makefile
> +++ b/drivers/memory/Makefile
> @@ -5,6 +5,7 @@
>  ifeq ($(CONFIG_DDR),y)
>  obj-$(CONFIG_OF)   += of_memory.o
>  endif
> +obj-$(CONFIG_TI_DAVINCI_AEMIF) += davinci-aemif.o
>  obj-$(CONFIG_TI_EMIF)  += emif.o
>  obj-$(CONFIG_MVEBU_DEVBUS) += mvebu-devbus.o
>  obj-$(CONFIG_TEGRA20_MC)   += tegra20-mc.o
> diff --git a/drivers/memory/davinci-aemif.c b/drivers/memory/davinci-aemif.c
> new file mode 100644
> index 000..e36b74b
> --- /dev/null
> +++ b/drivers/memory/davinci-aemif.c
> @@ -0,0 +1,415 @@
> +/*
> + * DaVinci/Keystone AEMIF driver
> + *
> + * Copyright (C) 2010 - 2013 Texas Instruments Incorporated. 
> http://www.ti.com/
> + * Copyright (C) Heiko Schocher 
> + * Copyright (C) Ivan Khoronzhuk 

Just checking: You meant Author: ? Code is already copyrighted to TI by
line above.

> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define TA_SHIFT   2
> +#define RHOLD_SHIFT4
> +#define RSTROBE_SHIFT  7
> +#define RSETUP_SHIFT   13
> +#define WHOLD_SHIFT17
> +#define WSTROBE_SHIFT  20
> +#define WSETUP_SHIFT   26
> +#define EW_SHIFT   30
> +#define SS_SHIFT   31
> +
> +#define TA(x)  ((x) << TA_SHIFT)
> +#define RHOLD(x)   ((x) << RHOLD_SHIFT)
> +#define RSTROBE(x) ((x) << RSTROBE_SHIFT)
> +#define RSETUP(x)  ((x) << RSETUP_SHIFT)
> +#define WHOLD(x)   ((x) << WHOLD_SHIFT)
> +#define WSTROBE(x) ((x) << WSTROBE_SHIFT)
> +#define WSETUP(x)  ((x) << WSETUP_SHIFT)
> +#define EW(x)  ((x) << EW_SHIFT)
> +#define SS(x)  ((x) << SS_SHIFT)
> +
> +#define ASIZE_MAX  0x1
> +#define TA_MAX 0x3
> +#define RHOLD_MAX  0x7
> +#define RSTROBE_MAX0x3f
> +#define RSETUP_MAX 0xf
> +#define WHOLD_MAX  0x7
> +#define WSTROBE_MAX0x3f
> +#define WSETUP_MAX 0xf
> +#define EW_MAX 0x1
> +#define SS_MAX 0x1
> +#define NUM_CS 4
> +
> +#define TA_VAL(x)  (((x) & TA(TA_MAX)) >> TA_SHIFT)
> +#define RHOLD_VAL(x)   (((x) & RHOLD(RHOLD_MAX)) >> RHOLD_SHIFT)
> +#define RSTROBE_VAL(x) (((x) & RSTROBE(RSTROBE_MAX)) >> RSTROBE_SHIFT)
> +#define RSETUP_VAL(x)  (((x) & RSETUP(RSETUP_MAX)) >> RSETUP_SHIFT)
> +#define WHOLD_VAL(x)   (((x) & WHOLD(WHOLD_MAX)) >> WHOLD_SHIFT)
> +#define WSTROBE_VAL(x) (((x) & WSTROBE(WSTROBE_MAX)) >> WSTROBE_SHIFT)
> +#define WSETUP_VAL(x)  (((x) & WSETUP(WSETUP_MAX)) >> WSETUP_SHIFT)
> +#define EW_VAL(x)  (((x) & EW(EW_MAX)) >> EW_SHIFT)
> +#define SS_VAL(x)  (((x) & SS(SS_MAX)) >> SS_SHIFT)
> +
> +#define NRCSR_OFFSET   0x00
> +#define AWCCR_OFFSET   0x04
> +#define A1CR_OFFSET0x10
> +
> +#define ACR_ASIZE_MASK 0x3
> +#define ACR_EW_MASKBIT(30)
> +#define ACR_SS_MASKBIT(31)
> +#define ASIZE_16BIT1
> +
> 

Re: [PATCH 1/5] block: Make generic_make_request handle arbitrary sized bios

[Kent Overstreet]

On Mon, Nov 25, 2013 at 10:09:21PM -0800, Christoph Hellwig wrote:
> > +   q->bio_split = bioset_create(4, 0);
> > +   if (!q->bio_split)
> > +   goto fail_id;
> 
> How did we arrive at a mempool size of 4 to make sure we can always make
> progress with arbitrarily sized bios?  Shouldn't we document the design
> decision somewhere?

It just has to be nonzero to guarantee forward progress - the
bio_alloc_bioset() rescuer thing I did awhile back guarantees that.

> > +static struct bio *blk_bio_discard_split(struct request_queue *q,
> > +struct bio *bio,
> > +struct bio_set *bs)
> > +{
> 
> One fallout of this should be that it would allows us to impement
> a range UNMAP/TRIP much more easily, which would help dramatically
> with TRIM performance!

Cool!
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [BUG] 3.13-rc1 kernel crash when enable all tracepoints

[Jovi Zhangwei]

On Tue, Nov 26, 2013 at 2:33 PM, Masami Hiramatsu
 wrote:
> (2013/11/26 13:38), Jovi Zhangwei wrote:
>> Hi,
>>
>> I'm not sure this issue already be fixed or not, it can be reproduced
>> permanently.
>>
>> (I didn't use git-bisect yet, you guys might can understand it quickly)
>>
>> #echo 1 > /sys/kernel/debug/tracing/events/enable
>
> Thanks for reporting. I could reproduce it.
>
> To narrow this down, I tried to run the below command
>
> [tracing]# for i in events/*/*/enable ; do echo $i; echo 1 > $i; done
>
> And it ran through the end without any problem.
> Hm, next I checked the difference of available_events and set_event.
>
> [tracing]# diff available_events set_event
> 283d282
> < ftrace:function
>
> So, I guess it was caused by enabling ftrace:function, and
> it is unable to do that via set_event, nor events/ftrace/enable
> I'm not sure how, but it seems that ftrace:function can be
> enabled by the events/enable.
>
I'm not sure this relate with ftrace:function event, from the
crash log, it seems more like caused by lock events.

Now I only enable lock events (lockdep compiled in my box), below
two commands both can crash system.

#echo 1 > /sys/kernel/debug/tracing/events/lock/lock_acquire/enable
or.
#echo 1 > /sys/kernel/debug/tracing/events/lock/lock_release/enable

According to the log, it seems like a recursion tracing bug.

register lock event -> jump_label_update -> text_poke_bp ->
on_each_cpu -> local_apic_timer_interrupt -> ktime_get_update_offsets
-> lock_release

(Perhaps the crash you reproduced is another crash? similar crash log?)

Jovi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] timer: Add __sched to msleep() and msleep_interruptible()

[Yoshihiro YUNOMAE]

Hi,

Would you review this patch?

Thanks,
Yoshihiro YUNOMAE

(2013/11/11 17:18), Yoshihiro YUNOMAE wrote:

Add __sched to msleep() and msleep_interruptible() for avoiding to show
these functions in WCHAN. If a driver calls msleep() or msleep_interruptible()
in a lot of places, users cannot understand that the driver might sleep which
functions execute msleep() or msleep_interruptible(). So, by applying this
patch, users can confirm the function calling msleep() or msleep_interruptible()
from WCHAN.

Signed-off-by: Yoshihiro YUNOMAE 
Cc: Thomas Gleixner 
Cc: linux-kernel@vger.kernel.org
---
  kernel/timer.c |4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/kernel/timer.c b/kernel/timer.c
index 6582b82..cc1470f 100644
--- a/kernel/timer.c
+++ b/kernel/timer.c
@@ -1660,7 +1660,7 @@ void __init init_timers(void)
   * msleep - sleep safely even with waitqueue interruptions
   * @msecs: Time in milliseconds to sleep for
   */
-void msleep(unsigned int msecs)
+void __sched msleep(unsigned int msecs)
  {
unsigned long timeout = msecs_to_jiffies(msecs) + 1;

@@ -1674,7 +1674,7 @@ EXPORT_SYMBOL(msleep);
   * msleep_interruptible - sleep waiting for signals
   * @msecs: Time in milliseconds to sleep for
   */
-unsigned long msleep_interruptible(unsigned int msecs)
+unsigned long __sched msleep_interruptible(unsigned int msecs)
  {
unsigned long timeout = msecs_to_jiffies(msecs) + 1;


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



--
Yoshihiro YUNOMAE
Software Platform Research Dept. Linux Technology Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: yoshihiro.yunomae...@hitachi.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: GPF in aio_migratepage

[Kent Overstreet]

On Tue, Nov 26, 2013 at 01:01:32AM -0500, Dave Jones wrote:
> On Mon, Nov 25, 2013 at 10:26:45PM -0500, Dave Jones wrote:
>  > Hi Kent,
>  > 
>  > I hit the GPF below on a tree based on 
> 8e45099e029bb6b369b27d8d4920db8caff5ecce
>  > which has your commit e34ecee2ae791df674dfb466ce40692ca6218e43
>  > ("aio: Fix a trinity splat").  Is this another path your patch missed, or
>  > a completely different bug to what you were chasing ?
> 
> And here's another from a different path, this time on 32bit.

I'm pretty sure this is a different bug... it appears to be related to
aio ring buffer migration, which I don't think I've touched.

Any information on what it was doing at the time? I see exit_aio() in
the second backtrace, maybe some sort of race between migratepage and
ioctx teardown? But it is using the address space mapping, so I dunno.

I don't see what's protecting ctx->ring_pages - I imagine it's got to
have something to do with the page migration machinery but I have no
idea how that works. Ben?

> Oops: 0002 [#1] PREEMPT SMP DEBUG_PAGEALLOC
> Modules linked in: tun fuse hidp rfcomm bnep scsi_transport_iscsi l2tp_ppp 
> l2tp_netlink l2tp_core nfc caif_socket caif af_802154 phonet af_rxrpc 
> bluetooth rfkill can_raw can_bcm can llc2 pppoe pppox ppp_generic slhc irda 
> crc_ccitt rds af_key rose x25 atm netrom appletalk ipx p8023 p8022 psnap llc 
> ax25 nouveau video backlight mxm_wmi wmi i2c_algo_bit ttm drm_kms_helper drm 
> i2c_core kvm_intel kvm tg3 ptp pps_core libphy serio_raw pcspkr lpc_ich 
> microcode mfd_core rtc_cmos parport_pc parport shpchp xfs libcrc32c raid0 
> floppy
> CPU: 0 PID: 4517 Comm: trinity-child0 Not tainted 3.13.0-rc1+ #6 
> Hardware name: Dell Inc. Precision WorkStation 490
> /0DT031, BIOS A08 04/25/2008
> task: ed899630 ti: dea22000 task.ti: dea22000
> EIP: 0060:[] EFLAGS: 00010293 CPU: 0
> EIP is at aio_migratepage+0xad/0x126
> EAX: 0144 EBX: f6844ed8 ECX: deaf4a84 EDX: 6b6b6b6b
> ESI: f68dc508 EDI: deaf4800 EBP: dea23bcc ESP: dea23ba8
>  DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
> CR0: 8005003b CR2: 6b6b707b CR3: 2c985000 CR4: 07f0
> Stack:
>   0001 deaf4a84 0286 d709b280  f68dc508 c11c7955
>  f6844ed8 dea23c0c c116aa9f 0001 0001 c11c7955 c1179a33 
>   c114166d f6844ed8 f6844ed8 c1140fc9 dea23c0c  f6844ed8
> Call Trace:
>  [] ? free_ioctx+0x62/0x62
>  [] move_to_new_page+0x63/0x1bb
>  [] ? free_ioctx+0x62/0x62
>  [] ? mem_cgroup_prepare_migration+0xc1/0x243
>  [] ? isolate_migratepages_range+0x3fb/0x675
>  [] ? isolate_freepages_block+0x316/0x316
>  [] migrate_pages+0x614/0x72b
>  [] ? isolate_freepages_block+0x316/0x316
>  [] compact_zone+0x294/0x475
>  [] try_to_compact_pages+0x129/0x196
>  [] __alloc_pages_direct_compact+0x91/0x197
>  [] __alloc_pages_nodemask+0x863/0xa55
>  [] get_huge_zero_page+0x52/0xf9
>  [] do_huge_pmd_anonymous_page+0x24e/0x39f
>  [] ? __mem_cgroup_count_vm_event+0xa6/0x191
>  [] ? __mem_cgroup_count_vm_event+0xbf/0x191
>  [] handle_mm_fault+0x235/0xd9a
>  [] ? __do_page_fault+0xf8/0x5a1
>  [] __do_page_fault+0x160/0x5a1
>  [] ? __do_page_fault+0xf8/0x5a1
>  [] ? __do_page_fault+0x5a1/0x5a1
>  [] do_page_fault+0xd/0xf
>  [] error_code+0x6c/0x74
>  [] ? memcg_update_all_caches+0x23/0x6b
>  [] ? __copy_from_user_ll+0x30/0xdb
>  [] _copy_from_user+0x3f/0x55
>  [] SyS_setrlimit+0x27/0x50
>  [] ? SyS_gettimeofday+0x33/0x6d
>  [] ? trace_hardirqs_on_thunk+0xc/0x10
>  [] sysenter_do_call+0x12/0x32
> Code: 6e 8d 8f 84 02 00 00 89 c8 89 4d e4 e8 df bf 3f 00 89 45 e8 89 da 89 f0 
> e8 99 2b fa ff 8b 43 08 3b 47 54 8b 4d e4 73 06 8b 57 50 <89> 34 82 8b 55 e8 
> 89 c8 e8 aa c1 3f 00 8b 45 ec e8 28 c1 3f 00
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 6/7] sched: Clean up preempt_enable_no_resched() abuse

[Eliezer Tamir]

On 22/11/2013 13:30, Peter Zijlstra wrote:
> On Fri, Nov 22, 2013 at 08:56:00AM +0200, Eliezer Tamir wrote:
>> On 21/11/2013 15:39, Peter Zijlstra wrote:
>>> On Thu, Nov 21, 2013 at 03:26:17PM +0200, Eliezer Tamir wrote:
> 
> Please use local_clock(), yes its slightly more expensive, but I doubt
> you can actually measure the effects on sane hardware.

If we limit the discussion to sane hardware, I should mention that on
current Intel CPUs TSC is guaranteed to be monotonic for anything up to
8 sockets. Even on slightly older HS TSC skew is very small and should
not be an issue for this use case.

So:
Modern sane HW does not have this issue.
The people that do busy polling typically pin tasks to cores anyway.
You need cap_net_admin to use this setting.
There is no real damage if the issue happens.
This is fast-low-latency-path so we are very sensitive to adding even
a small cost.
Linus really didn't like adding to the cost of poll/select when busy
polling is not being used.

Having said that, since we need to fix the timeout issue you pointed
out, we will test the use of local_clock() and see if it matters or
not.

Again, I have no objection to changing the use of
preempt_enable_no_resched() to a plain preempt_enable().

Cheers,
Eliezer
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] procfs: also fix proc_reg_get_unmapped_area() for !MMU case

[Jan Beulich]

>>> On 25.11.13 at 23:13, Andrew Morton  wrote:
> On Mon, 25 Nov 2013 16:22:31 + "Jan Beulich"  wrote:
> 
>> Commit fad1a86e ("procfs: call default get_unmapped_area on MMU-present
>> architectures"), as its title says, took care of only the MMU case,
>> leaving the !MMU side still in the regressed state (returning -EIO in
>> all cases where pde->proc_fops->get_unmapped_area is NULL).
> 
> The changelog is rather mystifying unless the reader goes off and finds
> the fad1a86e changelog, so let's do that for them by adding this:
> 
> From the fad1a86e changelog:
> 
> : Commit c4fe24485729 ("sparc: fix PCI device proc file mmap(2)") added
> : proc_reg_get_unmapped_area in proc_reg_file_ops and
> : proc_reg_file_ops_no_compat, by which now mmap always returns EIO if
> : get_unmapped_area method is not defined for the target procfs file, which
> : causes regression of mmap on /proc/vmcore.
> : 
> : To address this issue, like get_unmapped_area(), call default
> : current->mm->get_unmapped_area on MMU-present architectures if
> : pde->proc_fops->get_unmapped_area, i.e.  the one in actual file operation
> : in the procfs file, is not defined.
> 
>> Signed-off-by: Jan Beulich 
>> Cc: HATAYAMA Daisuke 
>> Cc: Alexey Dobriyan 
>> Cc: David S. Miller  
> 
> I tagged this with
> 
>   Cc: [3.12.x]
> 
> OK?

Sure. I also see you didn't like the way I coded it, and put a
code restructuring patch on top...

Jan

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] video: add OpenCores VGA/LCD framebuffer driver

[Michal Simek]

On 11/22/2013 05:34 AM, Stefan Kristiansson wrote:
> This adds support for the VGA/LCD core available from OpenCores:
> http://opencores.org/project,vga_lcd
> 
> The driver have been tested together with both OpenRISC and
> ARM (socfpga) processors.
> 
> Signed-off-by: Stefan Kristiansson 
> ---
> Changes in v2:
> - Add Microblaze as an example user and fix a typo in Xilinx Zynq
> 
> Changes in v3:
> - Use devm_kzalloc instead of kzalloc
> - Remove superflous MODULE #ifdef
> ---
>  drivers/video/Kconfig  |  17 ++
>  drivers/video/Makefile |   1 +
>  drivers/video/ocfb.c   | 471 
> +
>  3 files changed, 489 insertions(+)
>  create mode 100644 drivers/video/ocfb.c
> 
> diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
> index 84b685f..3b3f31e 100644
> --- a/drivers/video/Kconfig
> +++ b/drivers/video/Kconfig
> @@ -979,6 +979,23 @@ config FB_PVR2
> (). Please see the file
> .
>  
> +config FB_OPENCORES
> + tristate "OpenCores VGA/LCD core 2.0 framebuffer support"
> + depends on FB
> + select FB_CFB_FILLRECT
> + select FB_CFB_COPYAREA
> + select FB_CFB_IMAGEBLIT
> + default n
> + help
> +   This enables support for the OpenCores VGA/LCD core.
> +
> +   The OpenCores VGA/LCD core is typically used together with
> +   softcore CPUs (e.g. OpenRISC or Microblaze) or hard processor
> +   systems (e.g. Altera socfpga or Xilinx Zynq) on FPGAs.
> +
> +   The source code and specification for the core is available at
> +   
> +
>  config FB_S1D13XXX
>   tristate "Epson S1D13XXX framebuffer support"
>   depends on FB
> diff --git a/drivers/video/Makefile b/drivers/video/Makefile
> index e8bae8d..ae17ddf 100644
> --- a/drivers/video/Makefile
> +++ b/drivers/video/Makefile
> @@ -150,6 +150,7 @@ obj-$(CONFIG_FB_NUC900)   += nuc900fb.o
>  obj-$(CONFIG_FB_JZ4740)+= jz4740_fb.o
>  obj-$(CONFIG_FB_PUV3_UNIGFX)  += fb-puv3.o
>  obj-$(CONFIG_FB_HYPERV)+= hyperv_fb.o
> +obj-$(CONFIG_FB_OPENCORES) += ocfb.o
>  
>  # Platform or fallback drivers go here
>  obj-$(CONFIG_FB_UVESA)+= uvesafb.o
> diff --git a/drivers/video/ocfb.c b/drivers/video/ocfb.c
> new file mode 100644
> index 000..3bf5f67
> --- /dev/null
> +++ b/drivers/video/ocfb.c
> @@ -0,0 +1,471 @@
> +/*
> + * OpenCores VGA/LCD 2.0 core frame buffer driver
> + *
> + * Copyright (C) 2013 Stefan Kristiansson, stefan.kristians...@saunalahti.fi
> + *
> + * This file is licensed under the terms of the GNU General Public License
> + * version 2.  This program is licensed "as is" without any warranty of any
> + * kind, whether express or implied.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/* OCFB register defines */
> +#define OCFB_CTRL0x000
> +#define OCFB_STAT0x004
> +#define OCFB_HTIM0x008
> +#define OCFB_VTIM0x00c
> +#define OCFB_HVLEN   0x010
> +#define OCFB_VBARA   0x014
> +#define OCFB_PALETTE 0x800
> +
> +#define OCFB_CTRL_VEN0x0001 /* Video Enable */
> +#define OCFB_CTRL_HIE0x0002 /* HSync Interrupt Enable */
> +#define OCFB_CTRL_PC 0x0800 /* 8-bit Pseudo Color Enable*/
> +#define OCFB_CTRL_CD80x /* Color Depth 8 */
> +#define OCFB_CTRL_CD16   0x0200 /* Color Depth 16 */
> +#define OCFB_CTRL_CD24   0x0400 /* Color Depth 24 */
> +#define OCFB_CTRL_CD32   0x0600 /* Color Depth 32 */
> +#define OCFB_CTRL_VBL1   0x /* Burst Length 1 */
> +#define OCFB_CTRL_VBL2   0x0080 /* Burst Length 2 */
> +#define OCFB_CTRL_VBL4   0x0100 /* Burst Length 4 */
> +#define OCFB_CTRL_VBL8   0x0180 /* Burst Length 8 */
> +
> +#define PALETTE_SIZE 256
> +
> +#define OCFB_NAME"OC VGA/LCD"
> +
> +static char *mode_option;
> +
> +static const struct fb_videomode default_mode = {
> + /* 640x480 @ 60 Hz, 31.5 kHz hsync */
> + NULL, 60, 640, 480, 39721, 40, 24, 32, 11, 96, 2,
> + 0, FB_VMODE_NONINTERLACED
> +};
> +
> +struct ocfb_dev {
> + struct fb_info info;
> + /* Physical and virtual addresses of control regs */
> + phys_addr_t regs_phys;
> + int regs_phys_size;
> + void __iomem *regs;
> + /* flag indicating whether the regs are little endian accessed */
> + int little_endian;
> + /* Physical and virtual addresses of framebuffer */
> + phys_addr_t fb_phys;
> + void __iomem *fb_virt;
> + u32 pseudo_palette[PALETTE_SIZE];
> +};
> +
> +struct ocfb_par {
> + void __iomem *pal_adr;
> +};
> +
> +static struct ocfb_par ocfb_par_priv;
> +
> +static struct fb_var_screeninfo ocfb_var;
> +static struct fb_fix_screeninfo ocfb_fix;
> +
> +#ifndef MODULE
> +static int __init ocfb_setup(char *options)
> +{
> + char *curr_opt;
> +
> + if (!options || 

Re: [PATCH 06/12] mtd: nand: davinci: adjust DT properties to MTD generic

[Sekhar Nori]

On Monday 11 November 2013 10:31 PM, Khoronzhuk, Ivan wrote:
> The properties davinci-ecc-mode, davinci-nand-use-bbt, davinci-nand-buswidth
> are MTD generic. Correct names for them are: nand-ecc-mode, nand-on-flash-bbt,
> nand-bus-width accordingly. So rename them in dts and documentation.
> 
> Signed-off-by: Ivan Khoronzhuk 
> ---
>  .../devicetree/bindings/mtd/davinci-nand.txt   |   25 
> 
>  drivers/mtd/nand/davinci_nand.c|   11 ++---
>  2 files changed, 28 insertions(+), 8 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/mtd/davinci-nand.txt 
> b/Documentation/devicetree/bindings/mtd/davinci-nand.txt
> index d2a3fc0..befaa5b 100644
> --- a/Documentation/devicetree/bindings/mtd/davinci-nand.txt
> +++ b/Documentation/devicetree/bindings/mtd/davinci-nand.txt
> @@ -37,7 +37,7 @@ Recommended properties :
>  - ti,davinci-mask-chipsel: mask for chipselect address. Needed to mask
> addresses for given chipselect.
> 
> -- ti,davinci-ecc-mode: operation mode of the NAND ecc mode. ECC mode
> +- nand-ecc-mode:   operation mode of the NAND ecc mode. ECC mode
> valid values for davinci driver:
> - "none"
> - "soft"
> @@ -45,10 +45,25 @@ Recommended properties :
> 
>  - ti,davinci-ecc-bits: used ECC bits, currently supported 1 or 4.
> 
> -- ti,davinci-nand-buswidth:buswidth 8 or 16.

Shouldn't we keep the documentation for existing bindings while just
marking them as deprecated?

Thanks,
Sekhar

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 09/10] PCI: Sort pci root bus resources list

[Steven Newbury]

> On Mon, Nov 25, 2013 at 6:28 PM, Yinghai Lu  wrote:
> > Some x86 systems expose above 4G 64bit mmio in _CRS as non-pref mmio range.
> > [   49.415281] PCI host bridge to bus :00
> > [   49.419921] pci_bus :00: root bus resource [bus 00-1e]
> > [   49.426107] pci_bus :00: root bus resource [io  0x-0x0cf7]
> > [   49.433041] pci_bus :00: root bus resource [io  0x1000-0x5fff]
> > [   49.440010] pci_bus :00: root bus resource [mem 
> > 0x000a-0x000b]
> > [   49.447768] pci_bus :00: root bus resource [mem 
> > 0xfed8c000-0xfedf]
> > [   49.455532] pci_bus :00: root bus resource [mem 
> > 0x9000-0x9fffbfff]
> > [   49.463259] pci_bus :00: root bus resource [mem 
> > 0x3800-0x381f]
> >
> > During assign unassigned 64bit mmio resource, it will go through
> > every non-pref mmio for root bus in pci_bus_alloc_resource().
> > As the loop is with pci_bus_for_each_resource(), and could have chance
> > to use under 4G mmio range instead of above 4G mmio range if the requested
> > range is not big enough, even it could handle above 4G 64bit pref mmio.
> >
> > For root bus, we can order list from high to low in 
> > pci_add_resource_offset(),
> > during creating root bus, it will still keep the same order in final bus
> > resource list.
> > pci_acpi_scan_root
> > ==> add_resources
> > ==> pci_add_resource_offset: # Add to temp resources
> > ==> pci_create_root_bus
> > ==> pci_bus_add_resource # add to final bus 
> > resources.
> >
> > After that, we can make sure 64bit pref mmio for pci bridges will be 
> > allocated
> > higest of mmio non-pref, and in this case it is above 4G instead of under 
> > 4G.
> 
> Sorry I'm so slow; I'd like to know what problem this solves, too.
> I'm trying to help people at distros figure out whether they will need
> to backport this change.

This series was originally instigated during my attempt to get a PCI
Radeon 5450 graphics card with a 32-bit PLX bridge working in a
(hot-plugable) docking station on a system which had insufficient free
resources below 4G.  The biggest PCI address space user in my case was
the integrated i965 graphics, which I wanted to also be working for my
use case.  Allowing the IGP to be mapped above 4G freed enough resources
to make my system work, and it's now been running this way for the last
couple of years. (I've been rebasing the series in my local kernel.)

I'm pretty sure there are other cases, particularly where hotplug is
required where maximising free PCI address space <4G is extremely
useful; and it's to my mind a generally a good principle to allocate
resources such that limited resources (large aligned ranges) are
preserved for allocations which *require* them.  Is this really any
different than ZONE_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/

Re: [PATCH v2 08/10] PCI: Try best to allocate pref mmio 64bit above 4g

[Guo Chao]

Hi, Bjorn:

On Mon, Nov 25, 2013 at 09:17:11PM -0700, Bjorn Helgaas wrote:
> On Mon, Nov 25, 2013 at 6:28 PM, Yinghai Lu  wrote:
> > When one of children resources does not support MEM_64, MEM_64 for
> > bridge get reset, so pull down whole pref resource on the bridge under 4G.
> >
> > If the bridge support pref mem 64, will only allocate that with pref mem64 
> > to
> > children that support it.
> > For children resources if they only support pref mem 32, will allocate them
> > from non pref mem instead.
> >
> > If the bridge only support 32bit pref mmio, will still have all children 
> > pref
> > mmio under that.
> 
> I can't figure out if this is supposed to fix a problem, and if so,
> what problem it is.  Can you include a URL for a bugzilla or other
> problem description?
>

This is intended to fix resource allocation problem when we expose
64-bit MMIO window in PowerNV platform. Please see issue 3 in:

http://www.spinics.net/lists/linux-pci/msg26472.html

Without this, any 32-bit prefetchable BARs will pull down the
prefetahable window to allocate resource from 32-bit non-prefetchable
range, preventing 64-bit MMIO from being used at all.

What's worse, in some machines, 32-bit range is too small to provide
fall back space for prefetchable window, causing all prefetchable
BAR failing to get address.

64-bit MMIO on PowerNV is still pending (but definitely in plan).
So if no one else complained, it seems not fix any problems in upstream.

Thanks,
Guo Chao

> > -v2: Add release bridge res support with bridge mem res for pref_mem 
> > children res.
> > -v3: refresh and make it can be applied early before for_each_dev_res 
> > patchset.
> >
> > Signed-off-by: Yinghai Lu 
> > Tested-by: Guo Chao 
> > ---
> >  drivers/pci/setup-bus.c | 133 
> > 
> >  drivers/pci/setup-res.c |  14 -
> >  2 files changed, 101 insertions(+), 46 deletions(-)
> >
> > diff --git a/drivers/pci/setup-bus.c b/drivers/pci/setup-bus.c
> > index 219a410..b98419e 100644
> > --- a/drivers/pci/setup-bus.c
> > +++ b/drivers/pci/setup-bus.c
> > @@ -711,12 +711,11 @@ static void pci_bridge_check_ranges(struct pci_bus 
> > *bus)
> > bus resource of a given type. Note: we intentionally skip
> > the bus resources which have already been assigned (that is,
> > have non-NULL parent resource). */
> > -static struct resource *find_free_bus_resource(struct pci_bus *bus, 
> > unsigned long type)
> > +static struct resource *find_free_bus_resource(struct pci_bus *bus,
> > +unsigned long type_mask, unsigned long type)
> >  {
> > int i;
> > struct resource *r;
> > -   unsigned long type_mask = IORESOURCE_IO | IORESOURCE_MEM |
> > - IORESOURCE_PREFETCH;
> >
> > pci_bus_for_each_resource(bus, r, i) {
> > if (r == _resource || r == _resource)
> > @@ -813,7 +812,8 @@ static void pbus_size_io(struct pci_bus *bus, 
> > resource_size_t min_size,
> > resource_size_t add_size, struct list_head *realloc_head)
> >  {
> > struct pci_dev *dev;
> > -   struct resource *b_res = find_free_bus_resource(bus, IORESOURCE_IO);
> > +   struct resource *b_res = find_free_bus_resource(bus, IORESOURCE_IO,
> > +   IORESOURCE_IO);
> > resource_size_t size = 0, size0 = 0, size1 = 0;
> > resource_size_t children_add_size = 0;
> > resource_size_t min_align, align;
> > @@ -913,15 +913,16 @@ static inline resource_size_t 
> > calculate_mem_align(resource_size_t *aligns,
> >   * guarantees that all child resources fit in this size.
> >   */
> >  static int pbus_size_mem(struct pci_bus *bus, unsigned long mask,
> > -unsigned long type, resource_size_t min_size,
> > -   resource_size_t add_size,
> > -   struct list_head *realloc_head)
> > +unsigned long type, unsigned long type2,
> > +resource_size_t min_size, resource_size_t add_size,
> > +struct list_head *realloc_head)
> >  {
> > struct pci_dev *dev;
> > resource_size_t min_align, align, size, size0, size1;
> > resource_size_t aligns[12]; /* Alignments from 1Mb to 2Gb */
> > int order, max_order;
> > -   struct resource *b_res = find_free_bus_resource(bus, type);
> > +   struct resource *b_res = find_free_bus_resource(bus,
> > +mask | IORESOURCE_PREFETCH, type);
> > unsigned int mem64_mask = 0;
> > resource_size_t children_add_size = 0;
> >
> > @@ -942,7 +943,8 @@ static int pbus_size_mem(struct pci_bus *bus, unsigned 
> > long mask,
> > struct resource *r = >resource[i];
> > resource_size_t r_size;
> >
> > -   if (r->parent || (r->flags & mask) != type)
> > +  

Re: [PATCH v3] video: add OpenCores VGA/LCD framebuffer driver

[Stefan Kristiansson]

On Sun, Nov 24, 2013 at 03:12:11PM +0100, Jean-Christophe PLAGNIOL-VILLARD 
wrote:
> On 06:34 Fri 22 Nov , Stefan Kristiansson wrote:
> > This adds support for the VGA/LCD core available from OpenCores:
> > http://opencores.org/project,vga_lcd
> > 
> > The driver have been tested together with both OpenRISC and
> > ARM (socfpga) processors.
> > 
> > Signed-off-by: Stefan Kristiansson 
> 
> Tomi hold on this one I need check fee stuff on it
> > ---
> > Changes in v2:
> > - Add Microblaze as an example user and fix a typo in Xilinx Zynq
> > 
> > Changes in v3:
> > - Use devm_kzalloc instead of kzalloc
> > - Remove superflous MODULE #ifdef
> > ---
> >  drivers/video/Kconfig  |  17 ++
> >  drivers/video/Makefile |   1 +
> >  drivers/video/ocfb.c   | 471 
> > +
> >  3 files changed, 489 insertions(+)
> >  create mode 100644 drivers/video/ocfb.c
> > 
> > diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
> > index 84b685f..3b3f31e 100644
> > --- a/drivers/video/Kconfig
> > +++ b/drivers/video/Kconfig
> > @@ -979,6 +979,23 @@ config FB_PVR2
> >   (). Please see the file
> >   .
> >  
> > +config FB_OPENCORES
> > +   tristate "OpenCores VGA/LCD core 2.0 framebuffer support"
> > +   depends on FB
> > +   select FB_CFB_FILLRECT
> > +   select FB_CFB_COPYAREA
> > +   select FB_CFB_IMAGEBLIT
> > +   default n
> non need
> 

Ok, let's get rid of that then.

I'll hold on to v4 for a while, since it sounded you potentially had some
additional comments coming up?

Stefan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 03/16] staging/lustre/nfs: writing to new files will return ENOENT

[Patrick Farrell]

Peng,

I'm sorry to say, this patch was reverted due to interoperability problems with 
2.1 servers (This either a slightly later [but still broken] version of the 
patch we discussed recently, or the same one.).  If Greg's accepted this 
upstream (and it looks like he has), it'll have to be reverted.

Sorry for the trouble here!

- Patrick

From: Peng Tao [bergw...@gmail.com]
Sent: Monday, November 25, 2013 8:04 PM
To: Greg Kroah-Hartman
Cc: linux-kernel@vger.kernel.org; Patrick Farrell; Cheng Shao; Peng Tao; 
Andreas Dilger
Subject: [PATCH 03/16] staging/lustre/nfs: writing to new files will return 
ENOENT

From: Patrick Farrell 

This happend with SLES11SP2 Lustre client, which in turn acts as an
NFS server, exporting a subtree of an Lustre fs through NFS.

We detected that whenever we are writing to a new file using, fx,
'echo blah > newfile', it will return ENOENT error. We found
out that this was caused by the anonymous dentry. In SLESS11SP2,
anonymous dentries are assigned '/' as the name, instead of an
empty string. When MDT handles the intent_open call, it will look
up the obj by the name if it is not an empty string, and thus
couldn't find it.

As MDS_OPEN_BY_FID is always set on this request, we never need
to send the name in this request.  The fid is already available
and should be used in case the file has been renamed.

Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-3544
Lustre-change: http://review.whamcloud.com/6920
Signed-off-by: Cheng Shao 
Signed-off-by: Patrick Farrell 
Reviewed-by: Bob Glossman 
Reviewed-by: Alexey Shvetsov 
Reviewed-by: Lai Siyao 
Reviewed-by: James Simmons 
Reviewed-by: Oleg Drokin 
Signed-off-by: Peng Tao 
Signed-off-by: Andreas Dilger 
---
 drivers/staging/lustre/lustre/llite/file.c |5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/lustre/lustre/llite/file.c 
b/drivers/staging/lustre/lustre/llite/file.c
index 82248e9..f36c5d8 100644
--- a/drivers/staging/lustre/lustre/llite/file.c
+++ b/drivers/staging/lustre/lustre/llite/file.c
@@ -368,8 +368,6 @@ static int ll_intent_file_open(struct file *file, void *lmm,
 {
struct ll_sb_info *sbi = ll_i2sbi(file->f_dentry->d_inode);
struct dentry *parent = file->f_dentry->d_parent;
-   const char *name = file->f_dentry->d_name.name;
-   const int len = file->f_dentry->d_name.len;
struct md_op_data *op_data;
struct ptlrpc_request *req;
__u32 opc = LUSTRE_OPC_ANY;
@@ -394,8 +392,9 @@ static int ll_intent_file_open(struct file *file, void *lmm,
}

op_data  = ll_prep_md_op_data(NULL, parent->d_inode,
- file->f_dentry->d_inode, name, len,
+ file->f_dentry->d_inode, NULL, 0,
  O_RDWR, opc, NULL);
+
if (IS_ERR(op_data))
return PTR_ERR(op_data);

--
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH V3 0/6] cpufreq: suspend early/resume late

[Lan Tianyu]

On 2013年11月25日 22:11, Viresh Kumar wrote:
> This patchset adds cpufreq callbacks to dpm_{suspend|resume}() for handling
> suspend/resume of cpufreq governors and core. This is required for early 
> suspend
> and late resume of governors and cpufreq core.
> 
> There are multiple problems that are fixed by this patch:
> - Nishanth Menon (TI) found an interesting problem on his platform, OMAP. His 
> board
>   wasn't working well with suspend/resume as calls for removing non-boot CPUs
>   was turning out into a call to drivers ->target() which then tries to play
>   with regulators. But regulators and their I2C bus were already suspended and
>   this resulted in a failure. Many platforms have such problems, samsung, 
> tegra,
>   etc.. They solved it with driver specific PM notifiers where they used to
>   disable their driver's ->target() routine. Most of these are updated in this
>   patchset to use new infrastructure.
> 
> - Lan Tianyu (Intel) & Jinhyuk Choi (Broadcom) found another issue where
>   tunables configuration for clusters/sockets with non-boot CPUs was getting
>   lost after suspend/resume, as we were notifying governors with
>   CPUFREQ_GOV_POLICY_EXIT on removal of the last cpu for that policy and so
>   deallocating memory for tunables. This is also fixed with this patch as 
> don't
>   allow any operation on Governors during suspend/resume now.
> 
> 
> So to solve these issues we introduce early suspend and late resume callbacks
> which would remove need of cpufreq drivers to implement PM notifiers to 
> disable
> transition after suspend and before resume.
> 
> @Nishanth: Can you please test V2 as well and confirm that suspend_noirq()
> doesn't work for you. I am sure it will not, but would be better if you 
> confirm
> that.
> 
> Viresh Kumar (6):
>   cpufreq: suspend governors on system suspend/hibernate
>   cpufreq: call driver's suspend/resume for each policy
>   cpufreq: Implement cpufreq_generic_suspend()
>   cpufreq: exynos: Use cpufreq_generic_suspend()
>   cpufreq: s5pv210: Use cpufreq_generic_suspend()
>   cpufreq: Tegra: Use cpufreq_generic_suspend()
> 

Patch 1-2,
Tested-by: Lan Tianyu 

>  drivers/base/power/main.c |   5 ++
>  drivers/cpufreq/cpufreq.c | 133 
> +-
>  drivers/cpufreq/exynos-cpufreq.c  |  97 ++-
>  drivers/cpufreq/s5pv210-cpufreq.c |  49 +-
>  drivers/cpufreq/tegra-cpufreq.c   |  54 ++--
>  include/linux/cpufreq.h   |   6 ++
>  6 files changed, 99 insertions(+), 245 deletions(-)
> 


-- 
Best regards
Tianyu Lan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v11 00/15] kmemcg shrinkers

[Vladimir Davydov]

Hi,

Thank you for the review. I agree with all your comments and I'll resend 
the fixed version soon.


If anyone still has something to say about the patchset, I'd be glad to 
hear from them.


On 11/25/2013 09:41 PM, Johannes Weiner wrote:

I ran out of steam reviewing these because there were too many things
that should be changed in the first couple patches.

I realize this is frustrating to see these type of complaints in v11
of a patch series, but the review bandwidth was simply exceeded back
when Glauber submitted this along with the kmem accounting patches.  A
lot of the kmemcg commits themselves don't even have review tags or
acks, but it all got merged anyway, and the author has moved on to
different projects...

Too much stuff slips past the only two people that have more than one
usecase on their agenda and are willing to maintain this code base -
which is in desparate need of rework and pushback against even more
drive-by feature dumps.  I have repeatedly asked to split the memcg
tree out of the memory tree to better deal with the vastly different
developmental stages of memcg and the rest of the mm code, to no
avail.  So I don't know what to do anymore, but this is not working.

Thoughts?


That's a pity, because w/o this patchset kmemcg is in fact useless. 
Perhaps, it's worth trying to split it? (not sure if it'll help much 
though since first 11 patches are rather essential :-( )


Thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Preventing IPI sending races in arch code

[Vineet Gupta]

On 11/26/2013 10:41 AM, Benjamin Herrenschmidt wrote:
>> Right, but the issue per-se is not clobbering of msg holder, but from POV of
>> > receiver, seeming coalescing of 2 set_bit writes to msg holder.
> That's fine. There's no expectation that N ipi_send_msg turn into N
> messages received... it turns into at least one.

OK, I was not aware of that relaxation in semantics.

Thx,
-Vineet
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] i2c-mux-pca954x: Disable mux after 200ms timeout

[Mike Looijmans]

Leaving the mux enabled causes needless I2C traffic on the downstream
bus. De-selecting after every request causes excess I2C traffic and
switching.

This patch implements a hybrid solution: After 200ms of inactivity,
the mux is disabled.

Signed-off-by: Mike Looijmans 
---
 drivers/i2c/muxes/i2c-mux-pca954x.c |   45 ---
 1 file changed, 42 insertions(+), 3 deletions(-)

diff --git a/drivers/i2c/muxes/i2c-mux-pca954x.c 
b/drivers/i2c/muxes/i2c-mux-pca954x.c
index a531d80..1241c97 100644
--- a/drivers/i2c/muxes/i2c-mux-pca954x.c
+++ b/drivers/i2c/muxes/i2c-mux-pca954x.c
@@ -41,6 +41,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -60,7 +61,8 @@ enum pca_type {
 struct pca954x {
enum pca_type type;
struct i2c_adapter *virt_adaps[PCA954X_MAX_NCHANS];
-
+   struct i2c_client *client;
+   struct delayed_work deselect_work;
u8 last_chan;   /* last register value */
 };
 
@@ -168,11 +170,43 @@ static int pca954x_select_chan(struct i2c_adapter *adap,
return ret;
 }
 
-static int pca954x_deselect_mux(struct i2c_adapter *adap,
+static void pca954x_deselect_work(struct work_struct *work)
+{
+   struct pca954x *data = container_of(
+   work, struct pca954x, deselect_work.work);
+   /* Use the adapter lock as a mutex because any method that changes
+* the mux state will also hold this mutex. If the bus is in use,
+* the lock will assure that at least that transaction will
+* complete. */
+   i2c_lock_adapter(data->client->adapter);
+   if (data->last_chan != 0) {
+   int res;
+   /* Disable mux */
+   dev_dbg(>dev, "deselecting mux\n");
+   data->last_chan = 0;
+   res = pca954x_reg_write(data->client->adapter,
+   data->client, data->last_chan);
+   if (res < 0)
+   dev_err(>dev,
+   "%s: pca954x_reg_write failed: %d\n",
+   __func__, res);
+   }
+   i2c_unlock_adapter(data->client->adapter);
+}
+
+static int pca954x_deselect_mux_delayed(struct i2c_adapter *adap,
void *client, u32 chan)
 {
struct pca954x *data = i2c_get_clientdata(client);
+   /* Setup timer to disable at a later interval */
+   schedule_delayed_work(>deselect_work, msecs_to_jiffies(200));
+   return 0;
+}
 
+static int pca954x_deselect_mux_immediate(struct i2c_adapter *adap,
+   void *client, u32 chan)
+{
+   struct pca954x *data = i2c_get_clientdata(client);
/* Deselect active channel */
data->last_chan = 0;
return pca954x_reg_write(adap, client, data->last_chan);
@@ -212,6 +246,8 @@ static int pca954x_probe(struct i2c_client *client,
 
data->type = id->driver_data;
data->last_chan = 0;   /* force the first selection */
+   data->client = client;
+   INIT_DELAYED_WORK(>deselect_work, pca954x_deselect_work);
 
/* Now create an adapter for each channel */
for (num = 0; num < chips[data->type].nchans; num++) {
@@ -231,7 +267,8 @@ static int pca954x_probe(struct i2c_client *client,
i2c_add_mux_adapter(adap, >dev, client,
force, num, class, pca954x_select_chan,
(pdata && pdata->modes[num].deselect_on_exit)
-   ? pca954x_deselect_mux : NULL);
+   ? pca954x_deselect_mux_immediate
+   : pca954x_deselect_mux_delayed);
 
if (data->virt_adaps[num] == NULL) {
ret = -ENODEV;
@@ -264,6 +301,8 @@ static int pca954x_remove(struct i2c_client *client)
const struct chip_desc *chip = [data->type];
int i;
 
+   cancel_delayed_work_sync(>deselect_work);
+
for (i = 0; i < chip->nchans; ++i)
if (data->virt_adaps[i]) {
i2c_del_mux_adapter(data->virt_adaps[i]);
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [BUG] 3.13-rc1 kernel crash when enable all tracepoints

[Masami Hiramatsu]

(2013/11/26 13:38), Jovi Zhangwei wrote:
> Hi,
> 
> I'm not sure this issue already be fixed or not, it can be reproduced
> permanently.
> 
> (I didn't use git-bisect yet, you guys might can understand it quickly)
> 
> #echo 1 > /sys/kernel/debug/tracing/events/enable

Thanks for reporting. I could reproduce it.

To narrow this down, I tried to run the below command

[tracing]# for i in events/*/*/enable ; do echo $i; echo 1 > $i; done

And it ran through the end without any problem.
Hm, next I checked the difference of available_events and set_event.

[tracing]# diff available_events set_event
283d282
< ftrace:function

So, I guess it was caused by enabling ftrace:function, and
it is unable to do that via set_event, nor events/ftrace/enable
I'm not sure how, but it seems that ftrace:function can be
enabled by the events/enable.

Thank you,

-- 
Masami HIRAMATSU
IT Management Research Dept. Linux Technology Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu...@hitachi.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] thermal: EXYNOS: always register TMU driver with core thermal framework

[Amit Kachhap]

On 11/25/13, Bartlomiej Zolnierkiewicz  wrote:
>
> Hi,
>
> Could you please also apply this patch?
>
> Best regards,
> --
> Bartlomiej Zolnierkiewicz
> Samsung R Institute Poland
> Samsung Electronics
>
> On Friday, October 04, 2013 02:38:25 PM Bartlomiej Zolnierkiewicz wrote:
>> There is little sense in having separate config option for
>> registering EXYNOS TMU driver with the core thermal framework.
>> Fix it by integrating EXYNOS_THERMAL_CORE config option with
>> EXYNOS_THERMAL one.
>>
Sorry for the late reply but this patch is not needed as in my opinion
as it is just decreasing the flexibility when only sensor hardware
needs to be initialised and all cooling is hw controlled.

Thanks,
Amit D
>> Signed-off-by: Bartlomiej Zolnierkiewicz 
>> Signed-off-by: Kyungmin Park 
>> ---
>>  drivers/thermal/samsung/Kconfig | 14 +++---
>>  drivers/thermal/samsung/Makefile|  2 +-
>>  drivers/thermal/samsung/exynos_thermal_common.h | 12 
>>  3 files changed, 4 insertions(+), 24 deletions(-)
>>
>> diff --git a/drivers/thermal/samsung/Kconfig
>> b/drivers/thermal/samsung/Kconfig
>> index f760389..04eabee 100644
>> --- a/drivers/thermal/samsung/Kconfig
>> +++ b/drivers/thermal/samsung/Kconfig
>> @@ -5,14 +5,6 @@ config EXYNOS_THERMAL
>>If you say yes here you get support for the TMU (Thermal Management
>>Unit) driver for SAMSUNG EXYNOS series of SoCs. This driver
>> initialises
>>the TMU, reports temperature and handles cooling action if defined.
>> -  This driver uses the Exynos core thermal APIs and TMU configuration
>> -  data from the supported SoCs.
>> -
>> -config EXYNOS_THERMAL_CORE
>> -bool "Core thermal framework support for EXYNOS SOCs"
>> -depends on EXYNOS_THERMAL
>> -help
>> -  If you say yes here you get support for EXYNOS TMU
>> -  (Thermal Management Unit) common registration/unregistration
>> -  functions to the core thermal layer and also to use the generic
>> -  CPU cooling APIs.
>> +  This driver uses the Exynos core thermal APIs, TMU configuration data
>> +  from the supported SoCs, common registration/unregistration functions
>> +  to the core thermal layer and also the generic CPU cooling APIs.
>> diff --git a/drivers/thermal/samsung/Makefile
>> b/drivers/thermal/samsung/Makefile
>> index c09d830..a829107 100644
>> --- a/drivers/thermal/samsung/Makefile
>> +++ b/drivers/thermal/samsung/Makefile
>> @@ -4,4 +4,4 @@
>>  obj-$(CONFIG_EXYNOS_THERMAL)+= exynos_thermal.o
>>  exynos_thermal-y:= exynos_tmu.o
>>  exynos_thermal-y+= exynos_tmu_data.o
>> -exynos_thermal-$(CONFIG_EXYNOS_THERMAL_CORE)+= 
>> exynos_thermal_common.o
>> +exynos_thermal-y+= exynos_thermal_common.o
>> diff --git a/drivers/thermal/samsung/exynos_thermal_common.h
>> b/drivers/thermal/samsung/exynos_thermal_common.h
>> index 3eb2ed9..8681679 100644
>> --- a/drivers/thermal/samsung/exynos_thermal_common.h
>> +++ b/drivers/thermal/samsung/exynos_thermal_common.h
>> @@ -88,20 +88,8 @@ struct thermal_sensor_conf {
>>  struct device *dev;
>>  };
>>
>> -/*Functions used exynos based thermal sensor driver*/
>> -#ifdef CONFIG_EXYNOS_THERMAL_CORE
>>  void exynos_unregister_thermal(struct thermal_sensor_conf *sensor_conf);
>>  int exynos_register_thermal(struct thermal_sensor_conf *sensor_conf);
>>  void exynos_report_trigger(struct thermal_sensor_conf *sensor_conf);
>> -#else
>> -static inline void
>> -exynos_unregister_thermal(struct thermal_sensor_conf *sensor_conf) {
>> return; }
>>
>> -static inline int
>> -exynos_register_thermal(struct thermal_sensor_conf *sensor_conf) { return
>> 0; }
>> -
>> -static inline void
>> -exynos_report_trigger(struct thermal_sensor_conf *sensor_conf) { return;
>> }
>> -
>> -#endif /* CONFIG_EXYNOS_THERMAL_CORE */
>>  #endif /* _EXYNOS_THERMAL_COMMON_H */
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc"
> in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH V2] cpufreq: Make sure CPU is running on a freq from freq-table

[viresh kumar]

On Tuesday 26 November 2013 07:31 AM, Viresh Kumar wrote:
> Probably just throw an print message that CPU found to be running on
> out of table frequency, and that got fixed..

And here is the patch to test:

From: Viresh Kumar 
Date: Mon, 18 Nov 2013 10:15:50 +0530
Subject: [PATCH] cpufreq: Make sure CPU is running on a freq from freq-table

Sometimes boot loaders set CPU frequency to a value outside of frequency table
present with cpufreq core. In such cases CPU might be unstable if it has to run
on that frequency for long duration of time and so its better to set it to a
frequency which is specified in freq-table. This also makes cpufreq stats
inconsistent as cpufreq-stats would fail to register because current frequency
of CPU isn't found in freq-table.

Because we don't want this change to effect boot process badly, we go for the
next freq which is >= policy->cur ('cur' must be set by now, otherwise we will
end up setting freq to lowest of the table as 'cur' is initialized to zero).

In case current frequency doesn't match any frequency from freq-table, we throw
warnings to user, so that user can get this fixed in their bootloaders or
freq-tables.

Reported-by: Carlos Hernandez 
Reported-and-tested-by: Nishanth Menon 
Signed-off-by: Viresh Kumar 
---
 drivers/cpufreq/cpufreq.c| 37 +
 drivers/cpufreq/freq_table.c | 24 
 include/linux/cpufreq.h  |  2 ++
 3 files changed, 63 insertions(+)

diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index 02d534d..5beb16d 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -1038,6 +1038,43 @@ static int __cpufreq_add_dev(struct device *dev, struct 
subsys_interface *sif,
}
}

+   /*
+* Sometimes boot loaders set CPU frequency to a value outside of
+* frequency table present with cpufreq core. In such cases CPU might be
+* unstable if it has to run on that frequency for long duration of time
+* and so its better to set it to a frequency which is specified in
+* freq-table. This also makes cpufreq stats inconsistent as
+* cpufreq-stats would fail to register because current frequency of CPU
+* isn't found in freq-table.
+*
+* Because we don't want this change to effect boot process badly, we go
+* for the next freq which is >= policy->cur ('cur' must be set by now,
+* otherwise we will end up setting freq to lowest of the table as 'cur'
+* is initialized to zero).
+*
+* We are passing target-freq as "policy->cur - 1" otherwise
+* __cpufreq_driver_target() would simply fail, as policy->cur will be
+* equal to target-freq.
+*/
+   if (has_target()) {
+   /* Are we running at unknown frequency ? */
+   ret = cpufreq_frequency_table_get_index(policy, policy->cur);
+   if (ret == -EINVAL) {
+   /* Warn user and fix it */
+   pr_warn("%s: CPU%d: running at invalid freq: %u KHz\n",
+   __func__, policy->cpu, policy->cur);
+   ret = __cpufreq_driver_target(policy, policy->cur - 1,
+   CPUFREQ_RELATION_L);
+   if (ret) {
+   pr_err("%s: Unable to set frequency from table: 
%d\n",
+   __func__, ret);
+   goto err_out_unregister;
+   }
+   pr_warn("%s: CPU%d: frequency changed to: %u KHz\n",
+   __func__, policy->cpu, policy->cur);
+   }
+   }
+
/* related cpus should atleast have policy->cpus */
cpumask_or(policy->related_cpus, policy->related_cpus, policy->cpus);

diff --git a/drivers/cpufreq/freq_table.c b/drivers/cpufreq/freq_table.c
index 3458d27..0d6cc0e 100644
--- a/drivers/cpufreq/freq_table.c
+++ b/drivers/cpufreq/freq_table.c
@@ -178,7 +178,31 @@ int cpufreq_frequency_table_target(struct cpufreq_policy 
*policy,
 }
 EXPORT_SYMBOL_GPL(cpufreq_frequency_table_target);

+int cpufreq_frequency_table_get_index(struct cpufreq_policy *policy,
+   unsigned int freq)
+{
+   struct cpufreq_frequency_table *table;
+   int index = -EINVAL, i = 0;
+
+   table = cpufreq_frequency_get_table(policy->cpu);
+   if (unlikely(!table)) {
+   pr_debug("%s: Unable to find freq_table\n", __func__);
+   return -ENOENT;
+   }
+
+   for (; table[i].frequency != CPUFREQ_TABLE_END; i++) {
+   if (table[i].frequency == freq) {
+   index = i;
+   break;
+   }
+   }
+
+   return index;
+}
+EXPORT_SYMBOL_GPL(cpufreq_frequency_table_get_index);
+
 static DEFINE_PER_CPU(struct cpufreq_frequency_table *, 

Re: [PATCH 2/5] mtip32xx: handle arbitrary size bios

[Christoph Hellwig]

On Mon, Nov 25, 2013 at 02:30:30PM -0800, Kent Overstreet wrote:
> We get a measurable performance increase by handling this in the driver when
> we're already looping over the biovec, instead of handling it separately in
> generic_make_request() (or bio_add_page() originally)

Given that Jens has a patch queue up to convert the driver to blk-mq
adjusting the blk-mq infrastructure to handle this might be a better
plan forward..

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/5] block: Make generic_make_request handle arbitrary sized bios

[Christoph Hellwig]

> + q->bio_split = bioset_create(4, 0);
> + if (!q->bio_split)
> + goto fail_id;

How did we arrive at a mempool size of 4 to make sure we can always make
progress with arbitrarily sized bios?  Shouldn't we document the design
decision somewhere?

> +static struct bio *blk_bio_discard_split(struct request_queue *q,
> +  struct bio *bio,
> +  struct bio_set *bs)
> +{

One fallout of this should be that it would allows us to impement
a range UNMAP/TRIP much more easily, which would help dramatically
with TRIM performance!

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] thermal: offer Samsung thermal support only when ARCH_EXYNOS is defined

[Amit Kachhap]

On 10/4/13, Bartlomiej Zolnierkiewicz  wrote:
> Menu for Samsung thermal support is visible on all Samsung
> platforms while thermal drivers are currently available only
> for EXYNOS SoCs. Fix it by replacing PLAT_SAMSUNG dependency
> with ARCH_EXYNOS one.
>
> Signed-off-by: Bartlomiej Zolnierkiewicz 
> Signed-off-by: Kyungmin Park 
Looks good, so
Acked-by: Amit Daniel Kachhap 

> ---
>  drivers/thermal/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
> index a709c63..05cf95c 100644
> --- a/drivers/thermal/Kconfig
> +++ b/drivers/thermal/Kconfig
> @@ -198,7 +198,7 @@ source "drivers/thermal/ti-soc-thermal/Kconfig"
>  endmenu
>
>  menu "Samsung thermal drivers"
> -depends on PLAT_SAMSUNG
> +depends on ARCH_EXYNOS
>  source "drivers/thermal/samsung/Kconfig"
>  endmenu
>
> --
> 1.8.2.3
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc"
> in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [V3 01/10] perf: New conditional branch filter criteria in branch stack sampling

[m...@ellerman.id.au]

Ideally your commit subject would contain a verb, preferably in the present
tense.

I think simply "perf: Add PERF_SAMPLE_BRANCH_COND" would be clearer.

On Wed, 2013-16-10 at 06:56:48 UTC, Anshuman Khandual wrote:
> POWER8 PMU based BHRB supports filtering for conditional branches.
> This patch introduces new branch filter PERF_SAMPLE_BRANCH_COND which
> will extend the existing perf ABI. Other architectures can provide
> this functionality with either HW filtering support (if present) or
> with SW filtering of instructions.
> 
> Signed-off-by: Anshuman Khandual 
> Reviewed-by: Stephane Eranian 
> ---
>  include/uapi/linux/perf_event.h | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/include/uapi/linux/perf_event.h b/include/uapi/linux/perf_event.h
> index 0b1df41..5da52b6 100644
> --- a/include/uapi/linux/perf_event.h
> +++ b/include/uapi/linux/perf_event.h
> @@ -160,8 +160,9 @@ enum perf_branch_sample_type {
>   PERF_SAMPLE_BRANCH_ABORT_TX = 1U << 7, /* transaction aborts */
>   PERF_SAMPLE_BRANCH_IN_TX= 1U << 8, /* in transaction */
>   PERF_SAMPLE_BRANCH_NO_TX= 1U << 9, /* not in transaction */
> + PERF_SAMPLE_BRANCH_COND = 1U << 10, /* conditional branches */
>  
> - PERF_SAMPLE_BRANCH_MAX  = 1U << 10, /* non-ABI */
> + PERF_SAMPLE_BRANCH_MAX  = 1U << 11, /* non-ABI */
>  };

This no longer applies against Linus' tree, you'll need to rebase it.

cheers
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [V3 02/10] powerpc, perf: Enable conditional branch filter for POWER8

[m...@ellerman.id.au]

On Wed, 2013-16-10 at 06:56:49 UTC, Anshuman Khandual wrote:
> Enables conditional branch filter support for POWER8
> utilizing MMCRA register based filter and also invalidates
> a BHRB branch filter combination involving conditional
> branches.
> 
> Signed-off-by: Anshuman Khandual 
> ---
>  arch/powerpc/perf/power8-pmu.c | 10 ++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/arch/powerpc/perf/power8-pmu.c b/arch/powerpc/perf/power8-pmu.c
> index 2ee4a70..6e28587 100644
> --- a/arch/powerpc/perf/power8-pmu.c
> +++ b/arch/powerpc/perf/power8-pmu.c
> @@ -580,11 +580,21 @@ static u64 power8_bhrb_filter_map(u64 
> branch_sample_type)
>   if (branch_sample_type & PERF_SAMPLE_BRANCH_IND_CALL)
>   return -1;
>  
> + /* Invalid branch filter combination - HW does not support */
> + if ((branch_sample_type & PERF_SAMPLE_BRANCH_ANY_CALL) &&
> + (branch_sample_type & PERF_SAMPLE_BRANCH_COND))
> + return -1;

What this doesn't make obvious is that the hardware doesn't support any
combinations. It just happens that these are the only two possibilities we
allow, and so this is the only combination we have to disallow.

>
>   if (branch_sample_type & PERF_SAMPLE_BRANCH_ANY_CALL) {
>   pmu_bhrb_filter |= POWER8_MMCRA_IFM1;
>   return pmu_bhrb_filter;
>   }
>  
> + if (branch_sample_type & PERF_SAMPLE_BRANCH_COND) {
> + pmu_bhrb_filter |= POWER8_MMCRA_IFM3;
> + return pmu_bhrb_filter;
> + }
> +
>   /* Every thing else is unsupported */
>   return -1;
>  }

I think it would be clearer if we actually checked for the possibilities we
allow and let everything else fall through, eg:

/* Ignore user/kernel/hv bits */
branch_sample_type &= ~PERF_SAMPLE_BRANCH_PLM_ALL;

if (branch_sample_type == PERF_SAMPLE_BRANCH_ANY)
return 0;

if (branch_sample_type == PERF_SAMPLE_BRANCH_ANY_CALL)
return POWER8_MMCRA_IFM1;
 
if (branch_sample_type == PERF_SAMPLE_BRANCH_COND)
return POWER8_MMCRA_IFM3;

return -1;

cheers
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [GIT PULL] Immutable biovecs

[Christoph Hellwig]

On Mon, Nov 25, 2013 at 01:52:16PM -0800, Kent Overstreet wrote:
> Jens - here's immutable biovecs, rebased and ready for 3.14. Changes since the
> last version of the series:

Can you do a resend of the patch series to all involved lists first so
we can have a detailed look at the current version?

> 
>  * bio_clone_bioset() retains the old behaviour, as previously discussed -
>bio_clone_fast() is being used by bcache, dm and the new bio_split().

Any chance to have a more descriptive name than bio_clone_fast?  Also
without having the actual patches in front of me, did you make sure to
document the different in semantics in detail?

>  * refactoring patches to use submit_bio_wait() and bio_for_each_segment()

Jens already applied the submit_bio_wait patch.  

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 00/12] kexec kernel efi runtime support

[Dave Young]

This is the resend of V4, there's no update for kexec-tools patches.

BTW, below is a git repo for anyone who want to test the patches:
https://github.com/daveyoung/linux.git
branch kexec-efi

To Boris: finally I created a git repo ;) Thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v4 01/12] efi: remove unused variables in __map_region

[Dave Young]

variables size and end is useless in this function, thus remove them.

Reported-by: Toshi Kani 
Signed-off-by: Dave Young 
Acked-by: Borislav Petkov 
---
 arch/x86/platform/efi/efi_64.c | 6 +-
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/arch/x86/platform/efi/efi_64.c b/arch/x86/platform/efi/efi_64.c
index bf286c3..c5a6491 100644
--- a/arch/x86/platform/efi/efi_64.c
+++ b/arch/x86/platform/efi/efi_64.c
@@ -148,15 +148,11 @@ void efi_setup_page_tables(void)
 static void __init __map_region(efi_memory_desc_t *md, u64 va)
 {
pgd_t *pgd = (pgd_t *)__va(real_mode_header->trampoline_pgd);
-   unsigned long pf = 0, size;
-   u64 end;
+   unsigned long pf = 0;
 
if (!(md->attribute & EFI_MEMORY_WB))
pf |= _PAGE_PCD;
 
-   size = md->num_pages << PAGE_SHIFT;
-   end  = va + size;
-
if (kernel_map_pages_in_pgd(pgd, md->phys_addr, va, md->num_pages, pf))
pr_warn("Error mapping PA 0x%llx -> VA 0x%llx!\n",
   md->phys_addr, va);
-- 
1.8.3.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v4 11/12] x86: reserve setup_data ranges late after parsing memmap cmdline

[Dave Young]

Kdump kernel using memmap=exactmap, move e820_reserve_setup_data after
parsing early params so they can be set reserved finally. Or kdump kernel
will warn about ioremap a normal ram range.

Signed-off-by: Dave Young 
---
 arch/x86/kernel/setup.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index ecf225e..4a18f2f 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -927,8 +927,6 @@ void __init setup_arch(char **cmdline_p)
iomem_resource.end = (1ULL << boot_cpu_data.x86_phys_bits) - 1;
setup_memory_map();
parse_setup_data();
-   /* update the e820_saved too */
-   e820_reserve_setup_data();
 
copy_edd();
 
@@ -990,6 +988,8 @@ void __init setup_arch(char **cmdline_p)
early_dump_pci_devices();
 #endif
 
+   /* update the e820_saved too */
+   e820_reserve_setup_data();
finish_e820_parsing();
 
if (efi_enabled(EFI_BOOT))
-- 
1.8.3.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: GPF in aio_migratepage

[Dave Jones]

On Mon, Nov 25, 2013 at 10:26:45PM -0500, Dave Jones wrote:
 > Hi Kent,
 > 
 > I hit the GPF below on a tree based on 
 > 8e45099e029bb6b369b27d8d4920db8caff5ecce
 > which has your commit e34ecee2ae791df674dfb466ce40692ca6218e43
 > ("aio: Fix a trinity splat").  Is this another path your patch missed, or
 > a completely different bug to what you were chasing ?

And here's another from a different path, this time on 32bit.


Oops: 0002 [#1] PREEMPT SMP DEBUG_PAGEALLOC
Modules linked in: tun fuse hidp rfcomm bnep scsi_transport_iscsi l2tp_ppp 
l2tp_netlink l2tp_core nfc caif_socket caif af_802154 phonet af_rxrpc bluetooth 
rfkill can_raw can_bcm can llc2 pppoe pppox ppp_generic slhc irda crc_ccitt rds 
af_key rose x25 atm netrom appletalk ipx p8023 p8022 psnap llc ax25 nouveau 
video backlight mxm_wmi wmi i2c_algo_bit ttm drm_kms_helper drm i2c_core 
kvm_intel kvm tg3 ptp pps_core libphy serio_raw pcspkr lpc_ich microcode 
mfd_core rtc_cmos parport_pc parport shpchp xfs libcrc32c raid0 floppy
CPU: 0 PID: 4517 Comm: trinity-child0 Not tainted 3.13.0-rc1+ #6 
Hardware name: Dell Inc. Precision WorkStation 490/0DT031, 
BIOS A08 04/25/2008
task: ed899630 ti: dea22000 task.ti: dea22000
EIP: 0060:[] EFLAGS: 00010293 CPU: 0
EIP is at aio_migratepage+0xad/0x126
EAX: 0144 EBX: f6844ed8 ECX: deaf4a84 EDX: 6b6b6b6b
ESI: f68dc508 EDI: deaf4800 EBP: dea23bcc ESP: dea23ba8
 DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
CR0: 8005003b CR2: 6b6b707b CR3: 2c985000 CR4: 07f0
Stack:
  0001 deaf4a84 0286 d709b280  f68dc508 c11c7955
 f6844ed8 dea23c0c c116aa9f 0001 0001 c11c7955 c1179a33 
  c114166d f6844ed8 f6844ed8 c1140fc9 dea23c0c  f6844ed8
Call Trace:
 [] ? free_ioctx+0x62/0x62
 [] move_to_new_page+0x63/0x1bb
 [] ? free_ioctx+0x62/0x62
 [] ? mem_cgroup_prepare_migration+0xc1/0x243
 [] ? isolate_migratepages_range+0x3fb/0x675
 [] ? isolate_freepages_block+0x316/0x316
 [] migrate_pages+0x614/0x72b
 [] ? isolate_freepages_block+0x316/0x316
 [] compact_zone+0x294/0x475
 [] try_to_compact_pages+0x129/0x196
 [] __alloc_pages_direct_compact+0x91/0x197
 [] __alloc_pages_nodemask+0x863/0xa55
 [] get_huge_zero_page+0x52/0xf9
 [] do_huge_pmd_anonymous_page+0x24e/0x39f
 [] ? __mem_cgroup_count_vm_event+0xa6/0x191
 [] ? __mem_cgroup_count_vm_event+0xbf/0x191
 [] handle_mm_fault+0x235/0xd9a
 [] ? __do_page_fault+0xf8/0x5a1
 [] __do_page_fault+0x160/0x5a1
 [] ? __do_page_fault+0xf8/0x5a1
 [] ? __do_page_fault+0x5a1/0x5a1
 [] do_page_fault+0xd/0xf
 [] error_code+0x6c/0x74
 [] ? memcg_update_all_caches+0x23/0x6b
 [] ? __copy_from_user_ll+0x30/0xdb
 [] _copy_from_user+0x3f/0x55
 [] SyS_setrlimit+0x27/0x50
 [] ? SyS_gettimeofday+0x33/0x6d
 [] ? trace_hardirqs_on_thunk+0xc/0x10
 [] sysenter_do_call+0x12/0x32
Code: 6e 8d 8f 84 02 00 00 89 c8 89 4d e4 e8 df bf 3f 00 89 45 e8 89 da 89 f0 
e8 99 2b fa ff 8b 43 08 3b 47 54 8b 4d e4 73 06 8b 57 50 <89> 34 82 8b 55 e8 89 
c8 e8 aa c1 3f 00 8b 45 ec e8 28 c1 3f 00

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v4 12/12] x86: kdebugfs do not use __va for getting setup_data virt addr

[Dave Young]

__va does not work in case memmap=exactmap, so let's always use ioremap_cache.

Signed-off-by: Dave Young 
---
 arch/x86/kernel/kdebugfs.c | 35 +++
 1 file changed, 11 insertions(+), 24 deletions(-)

diff --git a/arch/x86/kernel/kdebugfs.c b/arch/x86/kernel/kdebugfs.c
index dc1404b..185e1ca 100644
--- a/arch/x86/kernel/kdebugfs.c
+++ b/arch/x86/kernel/kdebugfs.c
@@ -33,7 +33,6 @@ static ssize_t setup_data_read(struct file *file, char __user 
*user_buf,
struct setup_data_node *node = file->private_data;
unsigned long remain;
loff_t pos = *ppos;
-   struct page *pg;
void *p;
u64 pa;
 
@@ -47,18 +46,12 @@ static ssize_t setup_data_read(struct file *file, char 
__user *user_buf,
count = node->len - pos;
 
pa = node->paddr + sizeof(struct setup_data) + pos;
-   pg = pfn_to_page((pa + count - 1) >> PAGE_SHIFT);
-   if (PageHighMem(pg)) {
-   p = ioremap_cache(pa, count);
-   if (!p)
-   return -ENXIO;
-   } else
-   p = __va(pa);
+   p = ioremap_cache(pa, count);
+   if (!p)
+   return -ENXIO;
 
remain = copy_to_user(user_buf, p, count);
-
-   if (PageHighMem(pg))
-   iounmap(p);
+   iounmap(p);
 
if (remain)
return -EFAULT;
@@ -109,7 +102,6 @@ static int __init create_setup_data_nodes(struct dentry 
*parent)
struct setup_data *data;
int error;
struct dentry *d;
-   struct page *pg;
u64 pa_data;
int no = 0;
 
@@ -126,16 +118,12 @@ static int __init create_setup_data_nodes(struct dentry 
*parent)
goto err_dir;
}
 
-   pg = pfn_to_page((pa_data+sizeof(*data)-1) >> PAGE_SHIFT);
-   if (PageHighMem(pg)) {
-   data = ioremap_cache(pa_data, sizeof(*data));
-   if (!data) {
-   kfree(node);
-   error = -ENXIO;
-   goto err_dir;
-   }
-   } else
-   data = __va(pa_data);
+   data = ioremap_cache(pa_data, sizeof(*data));
+   if (!data) {
+   kfree(node);
+   error = -ENXIO;
+   goto err_dir;
+   }
 
node->paddr = pa_data;
node->type = data->type;
@@ -143,8 +131,7 @@ static int __init create_setup_data_nodes(struct dentry 
*parent)
error = create_setup_data_node(d, no, node);
pa_data = data->next;
 
-   if (PageHighMem(pg))
-   iounmap(data);
+   iounmap(data);
if (error)
goto err_dir;
no++;
-- 
1.8.3.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v4 09/12] x86: add xloadflags bit for efi runtime support on kexec

[Dave Young]

Old kexec-tools can not load new kernel. The reason is previously kexec-tools
do not fill efi_info in x86 setup header thus efi init fail and switch
to noefi boot. In new kexec-tools it will by default fill efi_info and
pass other efi required infomation to 2nd kernel so kexec kernel efi
initialization will success finally.

To prevent from breaking userspace, add a new xloadflags bit so kexec-tools
will check the flag and switch to old logic.

changelog:
Matt: +&& defined(CONFIG_KEXEC)
HPA: document the flag.

Signed-off-by: Dave Young 
---
 Documentation/x86/boot.txt| 3 +++
 arch/x86/boot/header.S| 9 -
 arch/x86/include/uapi/asm/bootparam.h | 1 +
 3 files changed, 12 insertions(+), 1 deletion(-)

diff --git a/Documentation/x86/boot.txt b/Documentation/x86/boot.txt
index f4f268c..cb81741d 100644
--- a/Documentation/x86/boot.txt
+++ b/Documentation/x86/boot.txt
@@ -608,6 +608,9 @@ Protocol:   2.12+
- If 1, the kernel supports the 64-bit EFI handoff entry point
   given at handover_offset + 0x200.
 
+  Bit 4 (read): XLF_EFI_KEXEC
+   - If 1, the kernel supports kexec EFI boot with EFI runtime support.
+
 Field name:cmdline_size
 Type:  read
 Offset/size:   0x238/4
diff --git a/arch/x86/boot/header.S b/arch/x86/boot/header.S
index 9ec06a1..ec3b8ba 100644
--- a/arch/x86/boot/header.S
+++ b/arch/x86/boot/header.S
@@ -391,7 +391,14 @@ xloadflags:
 #else
 # define XLF23 0
 #endif
-   .word XLF0 | XLF1 | XLF23
+
+#if defined(CONFIG_X86_64) && defined(CONFIG_EFI) && defined(CONFIG_KEXEC)
+# define XLF4 XLF_EFI_KEXEC
+#else
+# define XLF4 0
+#endif
+
+   .word XLF0 | XLF1 | XLF23 | XLF4
 
 cmdline_size:   .long   COMMAND_LINE_SIZE-1 #length of the command line,
 #added with boot protocol
diff --git a/arch/x86/include/uapi/asm/bootparam.h 
b/arch/x86/include/uapi/asm/bootparam.h
index ed6afc9..505eecf 100644
--- a/arch/x86/include/uapi/asm/bootparam.h
+++ b/arch/x86/include/uapi/asm/bootparam.h
@@ -24,6 +24,7 @@
 #define XLF_CAN_BE_LOADED_ABOVE_4G (1<<1)
 #define XLF_EFI_HANDOVER_32(1<<2)
 #define XLF_EFI_HANDOVER_64(1<<3)
+#define XLF_EFI_KEXEC  (1<<4)
 
 #ifndef __ASSEMBLY__
 
-- 
1.8.3.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v4 06/12] efi: export efi runtime memory mapping to sysfs

[Dave Young]

kexec kernel will need exactly same mapping for
efi runtime memory ranges. Thus here export the
runtime ranges mapping to sysfs, kexec-tools
will assemble them and pass to 2nd kernel via
setup_data.

Introducing a new directly /sys/firmware/efi/runtime-map
Just like /sys/firmware/memmap. Containing below attribute
in each file of that directory:
attribute  num_pages  phys_addr  type  virt_addr

It will not work for efi 32bit. Only x86_64 currently.

Matt: s/efi-runtime-map.c/runtime-map.c
  change dir name to runtime-map
update to use desc_size in efi_runtime_map
cleaup the code, add function efi_save_runtime_map
improve err handling

Signed-off-by: Dave Young 
---
 .../ABI/testing/sysfs-firmware-efi-runtime-map |  45 +
 arch/x86/platform/efi/efi.c|  26 +++
 drivers/firmware/efi/Kconfig   |  10 ++
 drivers/firmware/efi/Makefile  |   1 +
 drivers/firmware/efi/efi.c |   3 +-
 drivers/firmware/efi/runtime-map.c | 199 +
 include/linux/efi.h|   6 +
 7 files changed, 289 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/ABI/testing/sysfs-firmware-efi-runtime-map
 create mode 100644 drivers/firmware/efi/runtime-map.c

diff --git a/Documentation/ABI/testing/sysfs-firmware-efi-runtime-map 
b/Documentation/ABI/testing/sysfs-firmware-efi-runtime-map
new file mode 100644
index 000..dab8d41
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-firmware-efi-runtime-map
@@ -0,0 +1,45 @@
+What:  /sys/firmware/efi/runtime-map/
+Date:  Oct 2013
+Contact:   Dave Young 
+Description:
+   Switching efi runtime services to virtual mode requires
+   that all efi memory ranges which has the runtime attribute
+   bit set to be mapped to virtual addresses.
+
+   In kexec kernel kernel can not entering virtual mode again
+   because there's a limitation that SetVirtualAddressMap can
+   only be called once for entering virtual mode. But kexec
+   kernel still need maintain same physical address to virtual
+   address mapping as the 1st kernel. The mappings are exported
+   to sysfs so userspace tools can reassemble them and pass them
+   into kexec kernel.
+
+   /sys/firmware/efi/runtim-map/ is what kernel export for
+   this purpose. The structure is as follows:
+
+   subdirectories are named with the number of the memory range:
+
+   /sys/firmware/efi/runtime-map/0
+   /sys/firmware/efi/runtime-map/1
+   /sys/firmware/efi/runtime-map/2
+   /sys/firmware/efi/runtime-map/3
+   ...
+
+   Each subdirectory contains five files:
+
+   attribute : The attribute of the memory range.
+   num_pages : The size of the memory range in page number.
+   phys_addr : The start physical address of the memory range.
+   type  : The type of the memory range.
+   virt_addr : The start virtual address of the memory range.
+
+   Above values are all hexadecimal number with the '0x' prefix.
+
+   So, for example:
+
+   /sys/firmware/efi/runtime-map/0/attribute
+   /sys/firmware/efi/runtime-map/0/num_pages
+   /sys/firmware/efi/runtime-map/0/phys_addr
+   /sys/firmware/efi/runtime-map/0/type
+   /sys/firmware/efi/runtime-map/0/virt_addr
+...
diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
index 2a292aa..c3a2aaa 100644
--- a/arch/x86/platform/efi/efi.c
+++ b/arch/x86/platform/efi/efi.c
@@ -76,6 +76,9 @@ static __initdata efi_config_table_type_t arch_tables[] = {
{NULL_GUID, NULL, NULL},
 };
 
+void *efi_runtime_map;
+int nr_efi_runtime_map;
+
 /*
  * Returns 1 if 'facility' is enabled, 0 otherwise.
  */
@@ -811,6 +814,21 @@ static void __init efi_merge_regions(void)
}
 }
 
+static int __init efi_save_runtime_map(efi_memory_desc_t *md)
+{
+   efi_runtime_map = krealloc(efi_runtime_map,
+   (nr_efi_runtime_map + 1) *
+   memmap.desc_size, GFP_KERNEL);
+   if (!efi_runtime_map)
+   return -ENOMEM;
+
+   memcpy(efi_runtime_map + nr_efi_runtime_map * memmap.desc_size,
+   md, memmap.desc_size);
+   nr_efi_runtime_map++;
+
+   return 0;
+}
+
 /*
  * Map efi memory ranges for runtime serivce and update new_memmap with virtual
  * addresses.
@@ -821,6 +839,7 @@ static void * __init efi_map_regions(int *count)
void *p, *new_memmap = NULL;
unsigned long size;
u64 end, systab;
+   int error = 0;
 
for (p = memmap.map; p < memmap.map_end; p 

[PATCH v4 10/12] x86: export x86 boot_params to sysfs

[Dave Young]

kexec-tools use boot_params for getting the 1st kernel hardware_subarch,
the kexec kernel efi runtime support also need read the old efi_info from
boot_params. Currently it exists in debugfs which is not a good place for
such infomation. Per HPA, we should avoid of "sploit debugfs".

In this patch /sys/kernel/boot_params are exported, also the setup_data
is exported as a subdirectory. For original debugfs since it's already
there for long time and kexec-tools is using it for hardware_subarch so
let's do not remove them for now.

Structure are like below:

/sys/kernel/boot_params
├── data/* binary data for boot_params */
├── setup_data  /* subdirectory for setup_data if there's any */
│   ├── 0   /* the first setup_data node */
│   │   ├── data/* binary data for setup_data node 0 */
│   │   └── type/* setup_data type of setup_data node 0, hex string */
|   [snip]  /* other setup_data nodes ... */
└── version /* hex string for boot protocal version */

Changelog:
Greg: use __ATTR_RO() and group attr.

Signed-off-by: Dave Young 
---
 Documentation/ABI/testing/sysfs-kernel-boot_params |  40 +++
 arch/x86/kernel/Makefile   |   2 +-
 arch/x86/kernel/ksysfs.c   | 339 +
 3 files changed, 380 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/ABI/testing/sysfs-kernel-boot_params
 create mode 100644 arch/x86/kernel/ksysfs.c

diff --git a/Documentation/ABI/testing/sysfs-kernel-boot_params 
b/Documentation/ABI/testing/sysfs-kernel-boot_params
new file mode 100644
index 000..8014a93
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-kernel-boot_params
@@ -0,0 +1,40 @@
+What:  /sys/kernel/boot_params
+Date:  November 2013
+Contact:   Dave Young 
+Description:
+   The /sys/kernel/boot_params directory contains two
+   files: "data" and "version" and one subdirectory "setup_data".
+   It is used to export the kernel boot parameters of x86
+   platform to user space for kexec and debugging purpose.
+
+   If there's no setup_data in boot_params the subdirectory will
+   not be created.
+
+   "data" file is the binary representation of struct boot_params.
+
+   "version" file is the string representation of boot
+   protocol version.
+
+   "setup_data" subdirectory contains the setup_data data
+   structure in boot_params. setup_data is maintained in kernel
+   as a link list. In "setup_data" subdirectory there's one
+   subdirectory for each link list node named with the number
+   of the list nodes. The list node subdirectory contains two
+   files "type" and "data". "type" file is the string
+   representation of setup_data type. "data" file is the binary
+   representation of setup_data payload.
+
+   The whole boot_params directory structure is like below:
+   /sys/kernel/boot_params
+   ├── data
+   ├── setup_data
+   │   ├── 0
+   │   │   ├── data
+   │   │   └── type
+   │   └── 1
+   │   ├── data
+   │   └── type
+   └── version
+
+Users:
+   Kexec Mailing List 
diff --git a/arch/x86/kernel/Makefile b/arch/x86/kernel/Makefile
index a5408b9..473a4bb 100644
--- a/arch/x86/kernel/Makefile
+++ b/arch/x86/kernel/Makefile
@@ -35,7 +35,7 @@ obj-y += alternative.o i8253.o pci-nommu.o 
hw_breakpoint.o
 obj-y  += tsc.o io_delay.o rtc.o
 obj-y  += pci-iommu_table.o
 obj-y  += resource.o
-
+obj-$(CONFIG_SYSFS)+= ksysfs.o
 obj-y  += process.o
 obj-y  += i387.o xsave.o
 obj-y  += ptrace.o
diff --git a/arch/x86/kernel/ksysfs.c b/arch/x86/kernel/ksysfs.c
new file mode 100644
index 000..3f91207
--- /dev/null
+++ b/arch/x86/kernel/ksysfs.c
@@ -0,0 +1,339 @@
+/*
+ * Architecture specific sysfs attributes in /sys/kernel
+ *
+ * Copyright (C) 2007, Intel Corp.
+ *  Huang Ying 
+ * Copyright (C) 2013, 2013 Red Hat, Inc.
+ *  Dave Young 
+ *
+ * This file is released under the GPLv2
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+static ssize_t version_show(struct kobject *kobj,
+   struct kobj_attribute *attr, char *buf)
+{
+   return sprintf(buf, "0x%04x\n", boot_params.hdr.version);
+}
+
+static struct kobj_attribute boot_params_version_attr = __ATTR_RO(version);
+
+static ssize_t boot_params_data_read(struct file *fp, struct kobject *kobj,
+struct bin_attribute *bin_attr,
+char *buf, loff_t off, 

[PATCH v4 08/12] efi: only print saved efi runtime maps instead of all memmap ranges for kexec

[Dave Young]

For kexec/kdump kernel efi runtime mappings are saved, printing original whole
memmap ranges does not make sense anymore. So introduce a new function to only
print runtime maps in case kexec/kdump kernel is used.

Signed-off-by: Dave Young 
---
 arch/x86/platform/efi/efi.c | 23 ++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
index fafeb40..c65b0b8 100644
--- a/arch/x86/platform/efi/efi.c
+++ b/arch/x86/platform/efi/efi.c
@@ -430,6 +430,24 @@ int __init efi_memblock_x86_reserve_range(void)
return 0;
 }
 
+/* for kexec kernel runtime maps are passed in setup_data */
+static void __init print_saved_runtime_map(void)
+{
+#ifdef EFI_DEBUG
+   int i;
+   efi_memory_desc_t *md;
+
+   for (i = 0; i < nr_efi_runtime_map; i++) {
+   md = esdata->map + i;
+   pr_info("mem%02u: type=%u, attr=0x%llx, "
+   "range=[0x%016llx-0x%016llx) (%lluMB)\n",
+   i, md->type, md->attribute, md->phys_addr,
+   md->phys_addr + (md->num_pages << EFI_PAGE_SHIFT),
+   (md->num_pages >> (20 - EFI_PAGE_SHIFT)));
+   }
+#endif  /*  EFI_DEBUG  */
+}
+
 static void __init print_efi_memmap(void)
 {
 #ifdef EFI_DEBUG
@@ -782,7 +800,10 @@ void __init efi_init(void)
x86_platform.set_wallclock = efi_set_rtc_mmss;
}
 #endif
-   print_efi_memmap();
+   if (esdata)
+   print_saved_runtime_map();
+   else
+   print_efi_memmap();
 }
 
 void __init efi_late_init(void)
-- 
1.8.3.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v4 00/12] kexec kernel efi runtime support

[Dave Young]

Hi,

Here is the V4 resend for supporting kexec kernel efi runtime.
Per pervious discussion I pass the 1st kernel efi runtime mapping
via setup_data to 2nd kernel. Besides of the runtime mapping
info I also pass the fw_vendor, runtime, config table, smbios
physical address in setup_data. EFI spec mentioned fw_vendor,
runtime, config table addresses will be converted to virt address
after entering virtual mode, but we will use it as physical address
in efi_init. For smbios EFI spec did not mention about the address
updating, but during my test on a HP workstation, the bios will
convert it to Virt addr, thus pass it in setup_data as well.

For fw_vendor, runtime, config table, I export them in /sys/firmware/
efi/, smbios is already in /sys/firmware/efi/systab.

For efi runtime mapping I add a new directory /sys/firmware/efi/
runtime-map/ like below
[dave@darkstar ~]$ tree /sys/firmware/efi/runtime-map/
/sys/firmware/efi/runtime-map/
├── 0
│   ├── attribute
│   ├── num_pages
│   ├── phys_addr
│   ├── type
│   └── virt_addr
├── 1
│   ├── attribute
│   ├── num_pages
│   ├── phys_addr
│   ├── type
│   └── virt_addr
[snip]
 
kexec-tools will assemble them as setup_data and pass to 2nd kernel.
I will send userspace patches as well.

Limitation is I only write support for x86_64, test on below machines:
Lenovo thinkpad t420
Dell inspiron 14 - 3421
HP Z420 workstation
Qemu + OVMF

Please help to review the patches.

The patches are based on matt's efi master tree

Changes from v1:
add one flag in xloadflags, so kexec-tools can safely load old kernel
without efi support.
coding style fixes
function name for map phys_addr to fixed virt_addr
Add ABI documentation for sysfs files

Changes from v2:
01/09: a new patch to remove unused variables in __map_region function
   catched by Toshi Kani
09/09: a new patch to export x86 boot_params to sysfs instead of use
   debugfs files
Matt: reuse __map_region instead do same thing in another function.
  add a wrapper function efi_map_region_fixed [02/09]
  check return value of krealloc
  sysfs dir name s/efi-runtime-map/runtime-map [06/09]
  use desc_size in efi_runtime_map
  for the xloadflags defination: +&& defined(CONFIG_KEXEC)
Greg: sysfs : one file one value for fw_vendor, runtime, tables. [05/09]
  Document them in ABI testing
HPA:  Document the new xloadflag
Also there's other function cleanup and improvement for error handling.

Changes from v3:
Greg: sysfs code move to use __ATTR_RO and attr_group
Boris: comments and code alignment

Added 3 new patches below
10-print-efi-runtime-memmap.patch
  - 10/12: print only runtime ranges in case EFI_DEBUG printing
11-reserve-setup-data-late.patch
  - fix a bug of kdump kernel, move function for reserving setup data
ranges late after parsing memmap= cmdline params because kdump kernel
will pass exact memmap late.
12-x86-kdebugfs-use-ioremap.patch
  - fix a bug of x86/kernel/kdebugfs.c, use ioremap instead of __va for
low mem because __va does not work for exact memmap=

Dave Young (12):
  efi: remove unused variables in __map_region
  efi: add a wrapper function efi_map_region_fixed
  efi: reserve boot service fix
  efi: cleanup efi_enter_virtual_mode function
  efi: export more efi table variable to sysfs
  efi: export efi runtime memory mapping to sysfs
  efi: passing kexec necessary efi data via setup_data
  efi: only print saved efi runtime maps instead of all memmap ranges
for kexec
  x86: add xloadflags bit for efi runtime support on kexec
  x86: export x86 boot_params to sysfs
  x86: reserve setup_data ranges late after parsing memmap cmdline
  x86: kdebugfs do not use __va for getting setup_data virt addr

 Documentation/ABI/testing/sysfs-firmware-efi   |  26 ++
 .../ABI/testing/sysfs-firmware-efi-runtime-map |  45 +++
 Documentation/ABI/testing/sysfs-kernel-boot_params |  40 +++
 Documentation/x86/boot.txt |   3 +
 arch/x86/boot/header.S |   9 +-
 arch/x86/include/asm/efi.h |  13 +
 arch/x86/include/uapi/asm/bootparam.h  |   2 +
 arch/x86/kernel/Makefile   |   2 +-
 arch/x86/kernel/kdebugfs.c |  35 +--
 arch/x86/kernel/ksysfs.c   | 339 +
 arch/x86/kernel/setup.c|   7 +-
 arch/x86/platform/efi/efi.c| 313 +++
 arch/x86/platform/efi/efi_32.c |   2 +
 arch/x86/platform/efi/efi_64.c |  16 +-
 drivers/firmware/efi/Kconfig   |  10 +
 drivers/firmware/efi/Makefile  |   1 +
 drivers/firmware/efi/efi.c |  47 ++-
 drivers/firmware/efi/runtime-map.c | 199 
 include/linux/efi.h|   9 +
 19 files changed, 1028 insertions(+), 90 deletions(-)
 create mode 100644 

[PATCH v4 07/12] efi: passing kexec necessary efi data via setup_data

[Dave Young]

Add a new setup_data type SETUP_EFI for kexec use.
Passing the saved fw_vendor, runtime, config tables and
efi runtime mappings.

When entering virtual mode, directly mapping the efi
runtime ragions which we passed in previously. And skip
the step to call SetVirtualAddressMap.

Specially for HP z420 workstation it need another variable
saving, it's the smbios physical address, the HP bios
also update the SMBIOS address after entering virtual mode
besides of the standard fw_vendor,runtime and config table.

Tested on ovmf+qemu, lenovo thinkpad, a dell laptop and an
HP z420 workstation.

v2: refresh based on previous patch changes, code cleanup.
v3: use ioremap instead of phys_to_virt for esdata

Signed-off-by: Dave Young 
---
 arch/x86/include/asm/efi.h|  12 +++
 arch/x86/include/uapi/asm/bootparam.h |   1 +
 arch/x86/kernel/setup.c   |   3 +
 arch/x86/platform/efi/efi.c   | 161 ++
 4 files changed, 160 insertions(+), 17 deletions(-)

diff --git a/arch/x86/include/asm/efi.h b/arch/x86/include/asm/efi.h
index 9fbaeb2..73d5643 100644
--- a/arch/x86/include/asm/efi.h
+++ b/arch/x86/include/asm/efi.h
@@ -133,6 +133,18 @@ extern void efi_sync_low_kernel_mappings(void);
 extern void efi_setup_page_tables(void);
 extern void __init old_map_region(efi_memory_desc_t *md);
 
+struct efi_setup_data {
+   u64 fw_vendor;
+   u64 runtime;
+   u64 tables;
+   u64 smbios;
+   u64 reserved[8];
+   efi_memory_desc_t map[0];
+};
+
+extern void parse_efi_setup(u64 phys_addr, u32 data_len);
+extern struct efi_setup_data *esdata;
+
 #ifdef CONFIG_EFI
 
 static inline bool efi_is_native(void)
diff --git a/arch/x86/include/uapi/asm/bootparam.h 
b/arch/x86/include/uapi/asm/bootparam.h
index c15ddaf..ed6afc9 100644
--- a/arch/x86/include/uapi/asm/bootparam.h
+++ b/arch/x86/include/uapi/asm/bootparam.h
@@ -6,6 +6,7 @@
 #define SETUP_E820_EXT 1
 #define SETUP_DTB  2
 #define SETUP_PCI  3
+#define SETUP_EFI  4
 
 /* ram_size flags */
 #define RAMDISK_IMAGE_START_MASK   0x07FF
diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index f0de629..ecf225e 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -447,6 +447,9 @@ static void __init parse_setup_data(void)
case SETUP_DTB:
add_dtb(pa_data);
break;
+   case SETUP_EFI:
+   parse_efi_setup(pa_data, data_len);
+   break;
default:
break;
}
diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
index c3a2aaa..fafeb40 100644
--- a/arch/x86/platform/efi/efi.c
+++ b/arch/x86/platform/efi/efi.c
@@ -78,6 +78,7 @@ static __initdata efi_config_table_type_t arch_tables[] = {
 
 void *efi_runtime_map;
 int nr_efi_runtime_map;
+struct efi_setup_data *esdata;
 
 /*
  * Returns 1 if 'facility' is enabled, 0 otherwise.
@@ -115,6 +116,32 @@ static int __init setup_storage_paranoia(char *arg)
 }
 early_param("efi_no_storage_paranoia", setup_storage_paranoia);
 
+void __init parse_efi_setup(u64 phys_addr, u32 data_len)
+{
+   int size;
+   struct setup_data *sdata;
+   u64 esdata_phys;
+
+   if (!efi_enabled(EFI_64BIT)) {
+   pr_warn("skipping setup_data on EFI 32BIT!");
+   return;
+   }
+
+   sdata = early_memremap(phys_addr, data_len);
+   if (!sdata)
+   return;
+
+   size = data_len - sizeof(struct setup_data);
+
+   esdata_phys = phys_addr + sizeof(struct setup_data);
+
+   nr_efi_runtime_map = (size - sizeof(struct efi_setup_data)) /
+   sizeof(efi_memory_desc_t);
+   early_iounmap(sdata, data_len);
+
+   /* iounmap esdata in function efi_enter_virtual_mode */
+   esdata = early_memremap(esdata_phys, size);
+}
 
 static efi_status_t virt_efi_get_time(efi_time_t *tm, efi_time_cap_t *tc)
 {
@@ -504,8 +531,12 @@ static int __init efi_systab_init(void *phys)
}
 
efi_systab.hdr = systab64->hdr;
-   efi_systab.fw_vendor = systab64->fw_vendor;
-   tmp |= systab64->fw_vendor;
+
+   if (esdata)
+   efi_systab.fw_vendor = (unsigned long)esdata->fw_vendor;
+   else
+   efi_systab.fw_vendor = systab64->fw_vendor;
+   tmp |= efi_systab.fw_vendor;
efi_systab.fw_revision = systab64->fw_revision;
efi_systab.con_in_handle = systab64->con_in_handle;
tmp |= systab64->con_in_handle;
@@ -519,13 +550,21 @@ static int __init efi_systab_init(void *phys)
tmp |= systab64->stderr_handle;
efi_systab.stderr = systab64->stderr;
tmp |= systab64->stderr;
-   efi_systab.runtime = (void *)(unsigned 

[PATCH v4 05/12] efi: export more efi table variable to sysfs

[Dave Young]

Export fw_vendor, runtime and config tables physical
addresses to /sys/firmware/efi/systab becaue kexec
kernel will need them.

>From EFI spec these 3 variables will be updated to
virtual address after entering virtual mode. But
kernel startup code will need the physical address.

changelog:
Greg: add standalone sysfs files instead of add lines to systab
Document them as testing ABI
Greg: use group attrs and is_visible
Boris: align comments lines

Signed-off-by: Dave Young 
---
 Documentation/ABI/testing/sysfs-firmware-efi | 26 
 arch/x86/platform/efi/efi.c  |  4 +++
 drivers/firmware/efi/efi.c   | 44 
 include/linux/efi.h  |  3 ++
 4 files changed, 77 insertions(+)
 create mode 100644 Documentation/ABI/testing/sysfs-firmware-efi

diff --git a/Documentation/ABI/testing/sysfs-firmware-efi 
b/Documentation/ABI/testing/sysfs-firmware-efi
new file mode 100644
index 000..9252a24
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-firmware-efi
@@ -0,0 +1,26 @@
+What:  /sys/firmware/efi/fw_vendor
+Date:  Nov 2013
+Contact:   Dave Young 
+Description:
+   Shows the physical address of firmware vendor in the EFI
+   system table.
+Users:
+   Kexec Mailing List 
+
+What:  /sys/firmware/efi/runtime
+Date:  Nov 2013
+Contact:   Dave Young 
+Description:
+   Shows the physical address of runtime service table in the
+   EFI system table.
+Users:
+   Kexec Mailing List 
+
+What:  /sys/firmware/efi/config_table
+Date:  Nov 2013
+Contact:   Dave Young 
+Description:
+   Shows the physical address of config table in the EFI
+   system table.
+Users:
+   Kexec Mailing List 
diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
index 480529a..2a292aa 100644
--- a/arch/x86/platform/efi/efi.c
+++ b/arch/x86/platform/efi/efi.c
@@ -653,6 +653,10 @@ void __init efi_init(void)
 
set_bit(EFI_SYSTEM_TABLES, _efi_facility);
 
+   efi.config_table = (unsigned long)efi.systab->tables;
+   efi.fw_vendor= (unsigned long)efi.systab->fw_vendor;
+   efi.runtime  = (unsigned long)efi.systab->runtime;
+
/*
 * Show what we know for posterity
 */
diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c
index 2e2fbde..5d85956 100644
--- a/drivers/firmware/efi/efi.c
+++ b/drivers/firmware/efi/efi.c
@@ -32,6 +32,9 @@ struct efi __read_mostly efi = {
.hcdp   = EFI_INVALID_TABLE_ADDR,
.uga= EFI_INVALID_TABLE_ADDR,
.uv_systab  = EFI_INVALID_TABLE_ADDR,
+   .fw_vendor  = EFI_INVALID_TABLE_ADDR,
+   .runtime= EFI_INVALID_TABLE_ADDR,
+   .config_table  = EFI_INVALID_TABLE_ADDR,
 };
 EXPORT_SYMBOL(efi);
 
@@ -71,13 +74,54 @@ static ssize_t systab_show(struct kobject *kobj,
 static struct kobj_attribute efi_attr_systab =
__ATTR(systab, 0400, systab_show, NULL);
 
+static ssize_t fw_vendor_show(struct kobject *kobj,
+   struct kobj_attribute *attr, char *buf)
+{
+   return sprintf(buf, "0x%lx\n", efi.fw_vendor);
+}
+
+static ssize_t runtime_show(struct kobject *kobj,
+   struct kobj_attribute *attr, char *buf)
+{
+   return sprintf(buf, "0x%lx\n", efi.runtime);
+}
+
+static ssize_t config_table_show(struct kobject *kobj,
+   struct kobj_attribute *attr, char *buf)
+{
+   return sprintf(buf, "0x%lx\n", efi.config_table);
+}
+
+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 attribute *efi_subsys_attrs[] = {
_attr_systab.attr,
+   _attr_fw_vendor.attr,
+   _attr_runtime.attr,
+   _attr_config_table.attr,
NULL,   /* maybe more in the future? */
 };
 
+static umode_t efi_attr_is_visible(struct kobject *kobj,
+   struct attribute *attr, int n)
+{
+   umode_t mode = attr->mode;
+
+   if (attr == _attr_fw_vendor.attr)
+   return (efi.fw_vendor == EFI_INVALID_TABLE_ADDR) ? 0 : mode;
+   else if (attr == _attr_runtime.attr)
+   return (efi.runtime == EFI_INVALID_TABLE_ADDR) ? 0 : mode;
+   else if (attr == _attr_config_table.attr)
+   return (efi.config_table == EFI_INVALID_TABLE_ADDR) ? 0 : mode;
+
+   return mode;
+}
+
 static struct attribute_group efi_subsys_attr_group = {
.attrs = efi_subsys_attrs,
+   .is_visible = efi_attr_is_visible,
 };
 
 static struct efivars generic_efivars;
diff --git a/include/linux/efi.h b/include/linux/efi.h
index 6c0ca52..fb60b10 100644
--- a/include/linux/efi.h
+++ b/include/linux/efi.h
@@ -556,6 

[PATCH v4 04/12] efi: cleanup efi_enter_virtual_mode function

[Dave Young]

Add two small functions:
efi_merge_regions and efi_map_regions, efi_enter_virtual_mode
calls them instead of embedding two long for loop.

v1->v2:
refresh; coding style fixes.

v2->v3:
Toshi Kani:
remove unused variable
Matt: check return value of krealloc.
v3->v4:
Boris: Stretch comment to 80 cols

Signed-off-by: Dave Young 
Acked-by: Borislav Petkov 
---
 arch/x86/platform/efi/efi.c | 109 +++-
 1 file changed, 66 insertions(+), 43 deletions(-)

diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
index 15e3b5e..480529a 100644
--- a/arch/x86/platform/efi/efi.c
+++ b/arch/x86/platform/efi/efi.c
@@ -773,44 +773,12 @@ void __init old_map_region(efi_memory_desc_t *md)
   (unsigned long long)md->phys_addr);
 }
 
-/*
- * This function will switch the EFI runtime services to virtual mode.
- * Essentially, we look through the EFI memmap and map every region that
- * has the runtime attribute bit set in its memory descriptor into the
- * ->trampoline_pgd page table using a top-down VA allocation scheme.
- *
- * The old method which used to update that memory descriptor with the
- * virtual address obtained from ioremap() is still supported when the
- * kernel is booted with efi=old_map on its command line. Same old
- * method enabled the runtime services to be called without having to
- * thunk back into physical mode for every invocation.
- *
- * The new method does a pagetable switch in a preemption-safe manner
- * so that we're in a different address space when calling a runtime
- * function. For function arguments passing we do copy the PGDs of the
- * kernel page table into ->trampoline_pgd prior to each call.
- */
-void __init efi_enter_virtual_mode(void)
+/* Merge contiguous regions of the same type and attribute */
+static void __init efi_merge_regions(void)
 {
+   void *p;
efi_memory_desc_t *md, *prev_md = NULL;
-   void *p, *new_memmap = NULL;
-   unsigned long size;
-   efi_status_t status;
-   u64 end, systab;
-   int count = 0;
 
-   efi.systab = NULL;
-
-   /*
-* We don't do virtual mode, since we don't do runtime services, on
-* non-native EFI
-*/
-   if (!efi_is_native()) {
-   efi_unmap_memmap();
-   return;
-   }
-
-   /* Merge contiguous regions of the same type and attribute */
for (p = memmap.map; p < memmap.map_end; p += memmap.desc_size) {
u64 prev_size;
md = p;
@@ -837,6 +805,18 @@ void __init efi_enter_virtual_mode(void)
prev_md = md;
 
}
+}
+
+/*
+ * Map efi memory ranges for runtime serivce and update new_memmap with virtual
+ * addresses.
+ */
+static void * __init efi_map_regions(int *count)
+{
+   efi_memory_desc_t *md;
+   void *p, *new_memmap = NULL;
+   unsigned long size;
+   u64 end, systab;
 
for (p = memmap.map; p < memmap.map_end; p += memmap.desc_size) {
md = p;
@@ -861,14 +841,60 @@ void __init efi_enter_virtual_mode(void)
}
 
new_memmap = krealloc(new_memmap,
- (count + 1) * memmap.desc_size,
- GFP_KERNEL);
+   (*count + 1) * memmap.desc_size,
+   GFP_KERNEL);
if (!new_memmap)
-   goto err_out;
+   goto ret;
 
-   memcpy(new_memmap + (count * memmap.desc_size), md,
+   memcpy(new_memmap + (*count * memmap.desc_size), md,
   memmap.desc_size);
-   count++;
+   (*count)++;
+   }
+
+ret:
+   return new_memmap;
+}
+
+/*
+ * This function will switch the EFI runtime services to virtual mode.
+ * Essentially, we look through the EFI memmap and map every region that
+ * has the runtime attribute bit set in its memory descriptor into the
+ * ->trampoline_pgd page table using a top-down VA allocation scheme.
+ *
+ * The old method which used to update that memory descriptor with the
+ * virtual address obtained from ioremap() is still supported when the
+ * kernel is booted with efi=old_map on its command line. Same old
+ * method enabled the runtime services to be called without having to
+ * thunk back into physical mode for every invocation.
+ *
+ * The new method does a pagetable switch in a preemption-safe manner
+ * so that we're in a different address space when calling a runtime
+ * function. For function arguments passing we do copy the PGDs of the
+ * kernel page table into ->trampoline_pgd prior to each call.
+ */
+void __init efi_enter_virtual_mode(void)
+{
+   efi_status_t status;
+   void *new_memmap = NULL;
+   int count = 0;
+
+   efi.systab = NULL;
+
+   /*
+* We don't do virtual mode, since we don't do runtime services, on
+* non-native EFI
+

[PATCH v4 02/12] efi: add a wrapper function efi_map_region_fixed

[Dave Young]

Kexec kernel will use saved runtime virtual mapping, so add a
new function efi_map_region_fixed for directly mapping a md
to md->virt.

The md is passed in from 1st kernel, the virtual addr is
saved in md->virt_addr.

Matt: coding style
  reuse __map_region
Boris: Strenthen comment lines to 80 cols.

Signed-off-by: Dave Young 
Acked-by: Borislav Petkov 
---
 arch/x86/include/asm/efi.h |  1 +
 arch/x86/platform/efi/efi_32.c |  2 ++
 arch/x86/platform/efi/efi_64.c | 10 ++
 3 files changed, 13 insertions(+)

diff --git a/arch/x86/include/asm/efi.h b/arch/x86/include/asm/efi.h
index 89a05b0..9fbaeb2 100644
--- a/arch/x86/include/asm/efi.h
+++ b/arch/x86/include/asm/efi.h
@@ -128,6 +128,7 @@ extern void efi_call_phys_epilog(void);
 extern void efi_unmap_memmap(void);
 extern void efi_memory_uc(u64 addr, unsigned long size);
 extern void __init efi_map_region(efi_memory_desc_t *md);
+extern void __init efi_map_region_fixed(efi_memory_desc_t *md);
 extern void efi_sync_low_kernel_mappings(void);
 extern void efi_setup_page_tables(void);
 extern void __init old_map_region(efi_memory_desc_t *md);
diff --git a/arch/x86/platform/efi/efi_32.c b/arch/x86/platform/efi/efi_32.c
index e94557c..7b3ec6e 100644
--- a/arch/x86/platform/efi/efi_32.c
+++ b/arch/x86/platform/efi/efi_32.c
@@ -47,6 +47,8 @@ void __init efi_map_region(efi_memory_desc_t *md)
old_map_region(md);
 }
 
+void __init efi_map_region_fixed(efi_memory_desc_t *md) {}
+
 void efi_call_phys_prelog(void)
 {
struct desc_ptr gdt_descr;
diff --git a/arch/x86/platform/efi/efi_64.c b/arch/x86/platform/efi/efi_64.c
index c5a6491..ff08cb1 100644
--- a/arch/x86/platform/efi/efi_64.c
+++ b/arch/x86/platform/efi/efi_64.c
@@ -199,6 +199,16 @@ void __init efi_map_region(efi_memory_desc_t *md)
md->virt_addr = efi_va;
 }
 
+/*
+ * kexec kernel will use efi_map_region_fixed to map efi runtime memory ranges.
+ * md->virt_addr is the original virtual address which had been mapped in kexec
+ * 1st kernel.
+ */
+void __init efi_map_region_fixed(efi_memory_desc_t *md)
+{
+   __map_region(md, md->virt_addr);
+}
+
 void __iomem *__init efi_ioremap(unsigned long phys_addr, unsigned long size,
 u32 type, u64 attribute)
 {
-- 
1.8.3.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v4 03/12] efi: reserve boot service fix

[Dave Young]

Current code check boot service region with kernel text region by:
start+size >= __pa_symbol(_text)
The end of the above region should be start + size - 1 instead.

I see this problem in ovmf + Fedora 19 grub boot:
text start: 100 md start: 80 md size: 80

Signed-off-by: Dave Young 
Acked-by: Borislav Petkov 
Acked-by: Toshi Kani 
---
 arch/x86/platform/efi/efi.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
index f8ec4da..15e3b5e 100644
--- a/arch/x86/platform/efi/efi.c
+++ b/arch/x86/platform/efi/efi.c
@@ -438,7 +438,7 @@ void __init efi_reserve_boot_services(void)
 * - Not within any part of the kernel
 * - Not the bios reserved area
*/
-   if ((start+size >= __pa_symbol(_text)
+   if ((start + size > __pa_symbol(_text)
&& start <= __pa_symbol(_end)) ||
!e820_all_mapped(start, start+size, E820_RAM) ||
memblock_is_region_reserved(start, size)) {
-- 
1.8.3.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] PCI: add a quirk for keeping Bus Master bit on shutdown

[Lan Tianyu]

On 2013年11月26日 11:33, Bjorn Helgaas wrote:
> Lan, do you have access to any Lynx Point boxes?  Can you test and see
> whether they hang on power-off also?  I suspect this might be something
> specific to the Acer box, not a generic Lynx Point issue.

Sure. I just get one such prototype laptop and power off works normally
on it.

-- 
Best regards
Tianyu Lan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: /proc/vmcore mmap() failure issue

[HATAYAMA Daisuke]

(2013/11/25 23:41), Vivek Goyal wrote:

On Mon, Nov 25, 2013 at 06:01:37PM +0900, HATAYAMA Daisuke wrote:

[..]

I agree to avoid this issue by fixing makedumpfile as workaround while to
fix kernel is so tough and risky. However, it sounds strange to me to fix
userspace side elaborately for such definite kernel issue whose cause is
known, so we should fix the kernel itself.




Otherwise, will you continue to add specific fixes into user tools to
address kernel issues like this case ?



makedumpfile supports a wide range of kernel versions and needs to satisfy
backward compatibility. mmap() on /proc/vmcore might be backported to some of
the old versions on some distributions if necessary. Then, it's hard to fix
each old kernel at each back port. The method that can be applied to all the
kernels in general, is necessary.

Also, looking at ia64 case where there's boot loader data on partial pages,
there could be other environments where partial pages contain other important
data other components have. So, the issue depends not only on kernels but also
other components such as boot loader and firmwares that can put data on
partial pages. We need to get there as long as there's important data there
and we have access to there.


Hi Atsushi, Hatayama,

So even if we fix the mmap() issue in kernel, looks like it will be a
good idea to ship the fix in makedumpfile as there have been a kernel
release where mmap() will cause issues.

Having said that, I think we need to fix it in kernel also. I was not sure
that what's the right fix. Should we truncate partial pages or should
we just copy partial pages from old memory to new kernel's memory and fill
partial page with zeros. And that's why I was hoping that makedumpfile
can fill the gap.

Copying partial pages to new memory seems like a safer approach. So may
be we can take a fix in makeudmpfile and another in kernel.

Hatayama, I know that in the past your initial mmap() patches were copying
partial pages to new kernel's memory. Would you like to resurrect that
patch again?



(Oh, I yesterday had totally forgotten partial page handling that was dropped
from mmap() patch set in the middle of development...)

Yes, but wait until next week.

--
Thanks.
HATAYAMA, Daisuke

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: Preventing IPI sending races in arch code

[Benjamin Herrenschmidt]

On Tue, 2013-11-26 at 10:17 +0530, Vineet Gupta wrote:
> On 11/26/2013 01:21 AM, Benjamin Herrenschmidt wrote:
> > On Mon, 2013-11-25 at 13:35 +, Vineet Gupta wrote:
> > 
> >> Before reading ur email I was coding something like below:
> >>
> >> void arch_send_ipi(int cpu, int type)
> >> {
> >>   u32 *pending_ptr = per_cpu_ptr(ipi_bits, cpu);
> >>
> >>   while (cmpxchg(pending_ptr, 0, 1 << type) != 0)
> >>cpu_relax();
> >>
> >>   raise_ipi(cpu);
> >> }
> > 
> > So you would have blocked the sender while there was already
> > a pending IPI on the target ? Why ?
> 
> A simplistic (but non optimal) way to cater to the race where 2 senders try to
> send the exact same msg to same receiver. Upon first IPI, receiver "consumes" 
> the
> msg (using xchg with 0) so the 2nd IPI seems "empty" i.e. no msg.

But there is no race...

> > The optimization proposed by Peter is actually the only interesting
> > change here, without it the existing set_bit was perfectly fine.
> 
> I'm not sure, see below.
> 
> > Remember that set_bit is atomic.
> 
> Right, but the issue per-se is not clobbering of msg holder, but from POV of
> receiver, seeming coalescing of 2 set_bit writes to msg holder.

That's fine. There's no expectation that N ipi_send_msg turn into N
messages received... it turns into at least one.

Just like MSIs or other edge interrupts

Cheers,
Ben.

> core0 core1   core2
> 
> set_bit 1 
> kick IPI-2set_bit 1   IPI-0 received
>   kick IPI-2  read+clear bit
>   IPI-1 received
>   no msg
> 
> -Vineet
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] cpufreq: cpufreq-cpu0: clk_round_rate() can return a zero upon error

[viresh kumar]

On Tuesday 26 November 2013 07:31 AM, Paul Walmsley wrote:
> 
> Treat both negative and zero return values from clk_round_rate()
> as errors.  This is needed since subsequent patches will convert
> clk_round_rate()'s return value to be an unsigned type, rather
> than a signed type, since some clock sources can generate rates
> higher than (2^31)-1 Hz.
> 
> Eventually, when calling clk_round_rate(), only a return value of
> zero will be considered a error.  All other values will be
> considered valid rates.  The comparison against values less than
> 0 is kept to preserve the correct behavior in the meantime.
> 
> Signed-off-by: Paul Walmsley 
> Cc: Rafael J. Wysocki 
> Cc: Viresh Kumar 
> Cc: Mike Turquette 
> ---
> Applies on v3.13-rc1.  See also:
> 
> http://marc.info/?l=linux-arm-kernel=138542591313620=2
> 
>  drivers/cpufreq/cpufreq-cpu0.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/cpufreq/cpufreq-cpu0.c b/drivers/cpufreq/cpufreq-cpu0.c
> index d4585ce2346c..0faf756f6197 100644
> --- a/drivers/cpufreq/cpufreq-cpu0.c
> +++ b/drivers/cpufreq/cpufreq-cpu0.c
> @@ -44,7 +44,7 @@ static int cpu0_set_target(struct cpufreq_policy *policy,
> unsigned int index)
>  int ret;
> 
>  freq_Hz = clk_round_rate(cpu_clk, freq_table[index].frequency * 1000);
> -if (freq_Hz < 0)
> +if (freq_Hz <= 0)
>  freq_Hz = freq_table[index].frequency * 1000;
> 
>  freq_exact = freq_Hz;

So, we will see another patch where you will do: s/<=/== ??
I am wondering if there is any other way we can get this solved, i.e. in a
single patchset.

Otherwise, for both SPEAr and cpu0 patches:

Acked-by: Viresh Kumar 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: Preventing IPI sending races in arch code

[Vineet Gupta]

On 11/26/2013 01:21 AM, Benjamin Herrenschmidt wrote:
> On Mon, 2013-11-25 at 13:35 +, Vineet Gupta wrote:
> 
>> Before reading ur email I was coding something like below:
>>
>> void arch_send_ipi(int cpu, int type)
>> {
>>   u32 *pending_ptr = per_cpu_ptr(ipi_bits, cpu);
>>
>>   while (cmpxchg(pending_ptr, 0, 1 << type) != 0)
>>  cpu_relax();
>>
>>   raise_ipi(cpu);
>> }
> 
> So you would have blocked the sender while there was already
> a pending IPI on the target ? Why ?

A simplistic (but non optimal) way to cater to the race where 2 senders try to
send the exact same msg to same receiver. Upon first IPI, receiver "consumes" 
the
msg (using xchg with 0) so the 2nd IPI seems "empty" i.e. no msg.


> The optimization proposed by Peter is actually the only interesting
> change here, without it the existing set_bit was perfectly fine.

I'm not sure, see below.

> Remember that set_bit is atomic.

Right, but the issue per-se is not clobbering of msg holder, but from POV of
receiver, seeming coalescing of 2 set_bit writes to msg holder.

core0   core1   core2

set_bit 1   
kick IPI-2  set_bit 1   IPI-0 received
kick IPI-2  read+clear bit
IPI-1 received
no msg

-Vineet

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v1 2/2] USB: storage: use sg_miter_* APIs to access scsi buffer

[Ming Lei]

We have sg_miter_* APIs for accessing scsi sg buffer, so
use them to make code clean and bug free.

Cc: Matthew Dharm 
Cc: Alan Stern 
Cc: Greg Kroah-Hartman 
Signed-off-by: Ming Lei 
---
 drivers/usb/storage/protocol.c |   80 +---
 1 file changed, 26 insertions(+), 54 deletions(-)

diff --git a/drivers/usb/storage/protocol.c b/drivers/usb/storage/protocol.c
index 5dfb4c3..f54e5fe 100644
--- a/drivers/usb/storage/protocol.c
+++ b/drivers/usb/storage/protocol.c
@@ -135,69 +135,41 @@ unsigned int usb_stor_access_xfer_buf(unsigned char 
*buffer,
unsigned int buflen, struct scsi_cmnd *srb, struct scatterlist **sgptr,
unsigned int *offset, enum xfer_buf_dir dir)
 {
-   unsigned int cnt;
+   unsigned int cnt = 0;
struct scatterlist *sg = *sgptr;
+   struct sg_mapping_iter miter;
+   unsigned int nents = scsi_sg_count(srb);
 
-   /* We have to go through the list one entry
-* at a time.  Each s-g entry contains some number of pages, and
-* each page has to be kmap()'ed separately.  If the page is already
-* in kernel-addressable memory then kmap() will return its address.
-* If the page is not directly accessible -- such as a user buffer
-* located in high memory -- then kmap() will map it to a temporary
-* position in the kernel's virtual address space.
-*/
-
-   if (!sg)
+   if (sg)
+   nents = sg_nents(sg);
+   else
sg = scsi_sglist(srb);
 
-   /* This loop handles a single s-g list entry, which may
-* include multiple pages.  Find the initial page structure
-* and the starting offset within the page, and update
-* the *offset and **sgptr values for the next loop.
-*/
-   cnt = 0;
-   while (cnt < buflen && sg) {
-   struct page *page = sg_page(sg) +
-   ((sg->offset + *offset) >> PAGE_SHIFT);
-   unsigned int poff = (sg->offset + *offset) & (PAGE_SIZE-1);
-   unsigned int sglen = sg->length - *offset;
-
-   if (sglen > buflen - cnt) {
-
-   /* Transfer ends within this s-g entry */
-   sglen = buflen - cnt;
-   *offset += sglen;
-   } else {
+   sg_miter_start(, sg, nents, dir == FROM_XFER_BUF ?
+   SG_MITER_FROM_SG: SG_MITER_TO_SG);
 
-   /* Transfer continues to next s-g entry */
-   *offset = 0;
-   sg = sg_next(sg);
-   }
+   if (!sg_miter_skip(, *offset))
+   return cnt;
+
+   while (sg_miter_next() && cnt < buflen) {
+   unsigned int len = min(miter.length, buflen - cnt);
+
+   if (dir == FROM_XFER_BUF)
+   memcpy(buffer + cnt, miter.addr, len);
+   else
+   memcpy(miter.addr, buffer + cnt, len);
 
-   /* Transfer the data for all the pages in this
-   * s-g entry.  For each page: call kmap(), do the
-   * transfer, and call kunmap() immediately after. */
-   while (sglen > 0) {
-   unsigned int plen = min(sglen, (unsigned int)
-   PAGE_SIZE - poff);
-   unsigned char *ptr = kmap(page);
-
-   if (dir == TO_XFER_BUF)
-   memcpy(ptr + poff, buffer + cnt, plen);
-   else
-   memcpy(buffer + cnt, ptr + poff, plen);
-   kunmap(page);
-
-   /* Start at the beginning of the next page */
-   poff = 0;
-   ++page;
-   cnt += plen;
-   sglen -= plen;
+   if (*offset + len < miter.piter.sg->length) {
+   *offset += len;
+   *sgptr = miter.piter.sg;
+   } else {
+   *offset = 0;
+   *sgptr = sg_next(miter.piter.sg);
}
+   cnt += len;
}
-   *sgptr = sg;
+   sg_miter_stop();
 
-   /* Return the amount actually transferred */
return cnt;
 }
 EXPORT_SYMBOL_GPL(usb_stor_access_xfer_buf);
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v1 1/2] lib/scatterlist: export sg_miter_skip()

[Ming Lei]

sg_copy_buffer() can't meet demand for some drrivers(such usb
mass storage), so we have to use the sg_miter_* APIs to access
sg buffer, then need export sg_miter_skip() for these drivers.

The API is needed for converting to sg_miter_* APIs in USB storage
driver for accessing sg buffer.

Acked-by: Andrew Morton 
Cc: FUJITA Tomonori 
Cc: Tejun Heo 
Cc: Jens Axboe 
Signed-off-by: Ming Lei 
---
 include/linux/scatterlist.h |1 +
 lib/scatterlist.c   |3 ++-
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/include/linux/scatterlist.h b/include/linux/scatterlist.h
index adae88f..a964f72 100644
--- a/include/linux/scatterlist.h
+++ b/include/linux/scatterlist.h
@@ -345,6 +345,7 @@ struct sg_mapping_iter {
 
 void sg_miter_start(struct sg_mapping_iter *miter, struct scatterlist *sgl,
unsigned int nents, unsigned int flags);
+bool sg_miter_skip(struct sg_mapping_iter *miter, off_t offset);
 bool sg_miter_next(struct sg_mapping_iter *miter);
 void sg_miter_stop(struct sg_mapping_iter *miter);
 
diff --git a/lib/scatterlist.c b/lib/scatterlist.c
index d16fa29..3a8e8e8 100644
--- a/lib/scatterlist.c
+++ b/lib/scatterlist.c
@@ -495,7 +495,7 @@ static bool sg_miter_get_next_page(struct sg_mapping_iter 
*miter)
  *   true if @miter contains the valid mapping.  false if end of sg
  *   list is reached.
  */
-static bool sg_miter_skip(struct sg_mapping_iter *miter, off_t offset)
+bool sg_miter_skip(struct sg_mapping_iter *miter, off_t offset)
 {
sg_miter_stop(miter);
 
@@ -513,6 +513,7 @@ static bool sg_miter_skip(struct sg_mapping_iter *miter, 
off_t offset)
 
return true;
 }
+EXPORT_SYMBOL(sg_miter_skip);
 
 /**
  * sg_miter_next - proceed mapping iterator to the next mapping
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2] Input: ads7846: Convert to hwmon_device_register_with_groups

[Guenter Roeck]

Simplify the code and create mandatory 'name' attribute by using
new hwmon API.

Also use is_visible to determine visible attributes instead of creating
several different attribute groups.

Signed-off-by: Guenter Roeck 
---
v2: Use hwmon_device_register_with_groups instead of
devm_hwmon_device_register_with_groups to keep
device removal aligned with resource removal.

 drivers/input/touchscreen/ads7846.c |   81 +++
 1 file changed, 25 insertions(+), 56 deletions(-)

diff --git a/drivers/input/touchscreen/ads7846.c 
b/drivers/input/touchscreen/ads7846.c
index ea19536..932d4cf 100644
--- a/drivers/input/touchscreen/ads7846.c
+++ b/drivers/input/touchscreen/ads7846.c
@@ -102,7 +102,6 @@ struct ads7846 {
struct regulator*reg;
 
 #if defined(CONFIG_HWMON) || defined(CONFIG_HWMON_MODULE)
-   struct attribute_group  *attr_group;
struct device   *hwmon;
 #endif
 
@@ -479,42 +478,36 @@ static inline unsigned vbatt_adjust(struct ads7846 *ts, 
ssize_t v)
 SHOW(in0_input, vaux, vaux_adjust)
 SHOW(in1_input, vbatt, vbatt_adjust)
 
-static struct attribute *ads7846_attributes[] = {
-   _attr_temp0.attr,
-   _attr_temp1.attr,
-   _attr_in0_input.attr,
-   _attr_in1_input.attr,
-   NULL,
-};
-
-static struct attribute_group ads7846_attr_group = {
-   .attrs = ads7846_attributes,
-};
+static umode_t ads7846_is_visible(struct kobject *kobj, struct attribute *attr,
+ int index)
+{
+   struct device *dev = container_of(kobj, struct device, kobj);
+   struct ads7846 *ts = dev_get_drvdata(dev);
 
-static struct attribute *ads7843_attributes[] = {
-   _attr_in0_input.attr,
-   _attr_in1_input.attr,
-   NULL,
-};
+   if (ts->model == 7843 && index < 2) /* in0, in1 */
+   return 0;
+   if (ts->model == 7845 && index != 2)/* in0 */
+   return 0;
 
-static struct attribute_group ads7843_attr_group = {
-   .attrs = ads7843_attributes,
-};
+   return attr->mode;
+}
 
-static struct attribute *ads7845_attributes[] = {
-   _attr_in0_input.attr,
+static struct attribute *ads7846_attributes[] = {
+   _attr_temp0.attr,   /* 0 */
+   _attr_temp1.attr,   /* 1 */
+   _attr_in0_input.attr,   /* 2 */
+   _attr_in1_input.attr,   /* 3 */
NULL,
 };
 
-static struct attribute_group ads7845_attr_group = {
-   .attrs = ads7845_attributes,
+static struct attribute_group ads7846_attr_group = {
+   .attrs = ads7846_attributes,
+   .is_visible = ads7846_is_visible,
 };
+__ATTRIBUTE_GROUPS(ads7846_attr);
 
 static int ads784x_hwmon_register(struct spi_device *spi, struct ads7846 *ts)
 {
-   struct device *hwmon;
-   int err;
-
/* hwmon sensors need a reference voltage */
switch (ts->model) {
case 7846:
@@ -535,43 +528,19 @@ static int ads784x_hwmon_register(struct spi_device *spi, 
struct ads7846 *ts)
break;
}
 
-   /* different chips have different sensor groups */
-   switch (ts->model) {
-   case 7846:
-   ts->attr_group = _attr_group;
-   break;
-   case 7845:
-   ts->attr_group = _attr_group;
-   break;
-   case 7843:
-   ts->attr_group = _attr_group;
-   break;
-   default:
-   dev_dbg(>dev, "ADS%d not recognized\n", ts->model);
-   return 0;
-   }
-
-   err = sysfs_create_group(>dev.kobj, ts->attr_group);
-   if (err)
-   return err;
-
-   hwmon = hwmon_device_register(>dev);
-   if (IS_ERR(hwmon)) {
-   sysfs_remove_group(>dev.kobj, ts->attr_group);
-   return PTR_ERR(hwmon);
-   }
+   ts->hwmon = hwmon_device_register_with_groups(>dev, spi->modalias,
+ ts, ads7846_attr_groups);
+   if (IS_ERR(ts->hwmon))
+   return PTR_ERR(ts->hwmon);
 
-   ts->hwmon = hwmon;
return 0;
 }
 
 static void ads784x_hwmon_unregister(struct spi_device *spi,
 struct ads7846 *ts)
 {
-   if (ts->hwmon) {
-   sysfs_remove_group(>dev.kobj, ts->attr_group);
+   if (ts->hwmon)
hwmon_device_unregister(ts->hwmon);
-   }
 }
 
 #else
-- 
1.7.9.7

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[BUG] 3.13-rc1 kernel crash when enable all tracepoints

[Jovi Zhangwei]

Hi,

I'm not sure this issue already be fixed or not, it can be reproduced
permanently.

(I didn't use git-bisect yet, you guys might can understand it quickly)

#echo 1 > /sys/kernel/debug/tracing/events/enable

[  160.472176] BUG: unable to handle kernel NULL pointer dereference
at   (null)
[  160.472176] IP: [] strlen+0x0/0x30
[  160.472176] PGD 7b67a067 PUD 788c6067 PMD 0
[  160.472176] Oops:  [#12] SMP
[  160.472176] Modules linked in: ebtable_nat ebtables joydev e1000
[  160.472176] CPU: 0 PID: 741 Comm: bash Tainted: G  D  3.13.0-rc1+ #16
[  160.472176] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2007
[  160.472176] task: 88007891e000 ti: 880074d04000 task.ti:
880074d04000
[  160.472176] RIP: 0010:[]  []
strlen+0x0/0x30
[  160.472176] RSP: 0018:88007fc03e40  EFLAGS: 00010006
[  160.472176] RAX: 0002 RBX: 88007bb19d80 RCX: 0002
[  160.472176] RDX: 8107a5ac RSI: 826eac88 RDI: 
[  160.472176] RBP: 88007fc03e88 R08: 0002 R09: 
[  160.472176] R10: 88007891e000 R11:  R12: 826eac88
[  160.472176] R13: 0001 R14: 0046 R15: 81c47880
[  160.472176] FS:  7fef34515740() GS:88007fc0()
knlGS:
[  160.472176] CS:  0010 DS:  ES:  CR0: 80050033
[  160.472176] CR2:  CR3: 7a492000 CR4: 06f0
[  160.472176] Stack:
[  160.472176]  810999e0 0002 0046
88007fc03ec0
[  160.472176]  8800788031a0 826eac88 8107a5ac
0046
[  160.472176]  0001 88007fc03ec0 8109e840
0082
[  160.472176] Call Trace:
[  160.472176]  
[  160.472176]  [] ? ftrace_raw_event_lock+0x50/0xe0
[  160.472176]  [] ? hrtimer_interrupt+0x7c/0x240
[  160.472176]  [] lock_release+0xe0/0x1f0
[  160.472176]  [] ktime_get_update_offsets+0x62/0x150
[  160.472176]  [] ? hrtimer_interrupt+0x7c/0x240
[  160.472176]  [] hrtimer_interrupt+0x7c/0x240
[  160.472176]  [] ? trace_event_buffer_lock_reserve+0x26/0x30
[  160.472176]  [] local_apic_timer_interrupt+0x37/0x60
[  160.472176]  [] smp_trace_apic_timer_interrupt+0x4a/0xc9
[  160.472176]  [] trace_apic_timer_interrupt+0x6f/0x80
[  160.472176]  
[  160.472176]  [] ? smp_call_function_many+0x25a/0x2c0
[  160.472176]  [] ? setup_data_read+0xa0/0xa0
[  160.472176]  [] ? lock_release+0x46/0x1f0
[  160.472176]  [] ? setup_data_read+0xa0/0xa0
[  160.472176]  [] ? lock_release+0x47/0x1f0
[  160.472176]  [] on_each_cpu+0x2d/0x60
[  160.472176]  [] ? lock_release+0x46/0x1f0
[  160.472176]  [] text_poke_bp+0xa8/0xc0
[  160.472176]  [] ? lock_release+0x46/0x1f0
[  160.472176]  [] arch_jump_label_transform+0x8e/0x100
[  160.472176]  [] __jump_label_update+0x5f/0x80
[  160.472176]  [] jump_label_update+0x9d/0xb0
[  160.472176]  [] static_key_slow_inc+0xad/0xb0
[  160.472176]  [] tracepoint_update_probe_range+0x139/0x160
[  160.472176]  [] tracepoint_probe_register+0x54/0xa0
[  160.472176]  [] ftrace_event_reg+0x69/0x90
[  160.472176]  [] __ftrace_event_enable_disable+0x5f/0x1b0
[  160.472176]  [] __ftrace_set_clr_event_nolock+0xc7/0xf0
[  160.472176]  [] system_enable_write+0x9b/0xe0
[  160.472176]  [] vfs_write+0xb4/0x1f0
[  160.472176]  [] SyS_write+0x49/0xa0
[  160.472176]  [] ? __audit_syscall_entry+0x9c/0xf0
[  160.472176]  [] system_call_fastpath+0x16/0x1b
[  160.472176] Code: 89 f8 48 89 e5 f6 82 e0 c7 85 81 20 74 15 0f 1f
44 00 00 48 83 c0 01 0f b6 10 f6 82 e0 c7 85 81 20 75 f0 5d c3 66 0f
1f 44 00 00 <80> 3f 00 55 48 89 e5 74 15 48 89 f8 0f 1f 40 00 48 83 c0
01 80
[  160.472176] RIP  [] strlen+0x0/0x30
[  160.472176]  RSP 
[  160.472176] CR2: 
[  160.472176] ---[ end trace cadf03f6f81c6eb9 ]---
[  160.472277] Shutting down cpus with NMI
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: ads7846: Convert to devm_hwmon_device_register_with_groups

[Guenter Roeck]

On 11/25/2013 07:03 PM, Dmitry Torokhov wrote:

Hi Guenter,

On Sat, Nov 23, 2013 at 01:37:00PM -0800, Guenter Roeck wrote:

Simplify the code and create mandatory 'name' attribute by using
new hwmon API.

Also use is_visible to determine visible attributes instead of creating
several different attribute groups.


This change does not quite work without converting the rest of the
driver to devm_ resources as it makes hwmon outlive regulator and other
essential resources when unbinding driver from the device.


Ok, I'll use hwmon_device_register_with_groups instead.

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 1/2] arch: hexagon: include: asm: add prefix "vm_" for all enum members in "hexagon_vm.h"

[Chen Gang]

On 11/25/2013 10:40 AM, Chen Gang wrote:
> Append "vm_" to all enum members (which are too common to make conflict
> with another sub-systems). The related error with allmodconfig:
> 
> CC [M]  drivers/md/raid1.o
>   drivers/md/raid1.c:1440:13: error: 'status' redeclared as different kind of 
> symbol
>   arch/hexagon/include/asm/hexagon_vm.h:76:2: note: previous definition of 
> 'status' was here
> 

Oh, sorry, The new prefix "vm_" is still conflict with others. One case
is below (bottom of this mail)

I will use "hvmc_" for VM_CACHE_OPS and "hvmi_" for VM_INT_OPS instead
of. If get no rejections within 1 day, I will send patch v2 for it.

And also I will merge the related 2 patches together (although they are
for 2 issues).

> 
> Signed-off-by: Chen Gang 
> ---
>  arch/hexagon/include/asm/hexagon_vm.h |   70 
>  1 files changed, 35 insertions(+), 35 deletions(-)
> 
> diff --git a/arch/hexagon/include/asm/hexagon_vm.h 
> b/arch/hexagon/include/asm/hexagon_vm.h
> index 67bb6d6..e1e0470 100644
> --- a/arch/hexagon/include/asm/hexagon_vm.h
> +++ b/arch/hexagon/include/asm/hexagon_vm.h
> @@ -55,27 +55,27 @@
>  #ifndef __ASSEMBLY__
>  
>  enum VM_CACHE_OPS {
> - ickill,
> - dckill,
> - l2kill,
> - dccleaninva,
> - icinva,
> - idsync,
> - fetch_cfg
> + vm_ickill,
> + vm_dckill,
> + vm_l2kill,
> + vm_dccleaninva,
> + vm_icinva,
> + vm_idsync,
> + vm_fetch_cfg
>  };
>  
>  enum VM_INT_OPS {
> - nop,
> - globen,
> - globdis,
> - locen,
> - locdis,
> - affinity,
> - get,
> - peek,
> - status,
> - post,
> - clear
> + vm_nop,
> + vm_globen,
> + vm_globdis,
> + vm_locen,
> + vm_locdis,
> + vm_affinity,
> + vm_get,

The new prefix "vm_" for "get" is still conflict with others:

CC [M]  drivers/virtio/virtio_mmio.o
  drivers/virtio/virtio_mmio.c:170:13: error: 'vm_get' redeclared as different 
kind of symbol
  arch/hexagon/include/asm/hexagon_vm.h:74:2: note: previous definition of 
'vm_get' was here


Thanks.
-- 
Chen Gang
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: kernel BUG at drivers/md/raid5.c:693!

[NeilBrown]

On Mon, 25 Nov 2013 10:53:23 +0100 Peter Zijlstra 
wrote:

> On Mon, Nov 25, 2013 at 10:35:22AM +1100, NeilBrown wrote:
> > Ingo/Peter: is it considered OK to call wake_up while holding a spinlock?
> 
> Yes, very much so. Doing a wakeup isn't _that_ expensive.

Oh good.  Thanks.

> 
> > Could "sleeping spinlocks" affect this at all? (some sample stack traces are
> > below).
> 
> Not entirely sure, are you referencing to -rt where me make spinlock_t
> pi-mutexes?

I'm not sure either.  Just stabbing in the dark really.

The stack trace in the previous email seemed to suggest that a process was
blocking inside a wake_up call, but it wasn't at all conclusive.  And I've
seen a few wake_ups in other stack traces which seem to be connected with
other deadlock.  Probably some sort of co-incidence.

Thanks,
NeilBrown


signature.asc
Description: PGP signature

Re: [PATCH v2] video: backlight: Remove backlight sysfs uevent

[Jingoo Han]

On Tuesday, November 12, 2013 12:39 PM, Kyungmin Park wrote:
>
> From: Kyungmin Park 
> 
> The most mobile phones have Ambient Light Sensors and it changes brightness 
> according lux.
> It means it changes backlight brightness frequently by just writing sysfs 
> node, so it generates uevent.
> 
> Usually there's no user to use this backlight changes. But it forks udev 
> worker threads and it takes
> about 5ms. The main problem is that it hurts other process activities. so 
> remove it.
> 
> Kay said
> "Uevents are for the major, low-frequent, global device state-changes,
>  not for carrying-out any sort of measurement data. Subsystems which
>  need that should use other facilities like poll()-able sysfs file or
>  any other subscription-based, client-tracking interface which does not
>  cause overhead if it isn't used. Uevents are not the right thing to
>  use here, and upstream udev should not paper-over broken kernel
>  subsystems."
> 
> Signed-off-by: Kyungmin Park 

Acked-by: Jingoo Han 

Best regards,
Jingoo Han

> ---
> v1: there's still user to use BACKLIGHT_UPDATE_SYSFS. so just remove store 
> sysfs node uevent
> 
> ---
> diff --git a/drivers/video/backlight/backlight.c 
> b/drivers/video/backlight/backlight.c
> index 94a403a..292cf99 100644
> --- a/drivers/video/backlight/backlight.c
> +++ b/drivers/video/backlight/backlight.c
> @@ -172,8 +172,6 @@ static ssize_t brightness_store(struct device *dev,
>   }
>   mutex_unlock(>ops_lock);
> 
> - backlight_generate_event(bd, BACKLIGHT_UPDATE_SYSFS);
> -
>   return rc;
>  }
>  static DEVICE_ATTR_RW(brightness);

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2/2 v2] i2c: exynos5: configure fifo_depth based on HSI2C module version

[Naveen Krishna Chatradhi]

fifo_depth of the HSI2C is not constant
Exynos5420 and Exynos5250 supports fifo_depth of 64bytes
Exynos5260 supports fifo_depth of 16bytes

This patch configures the fifo_depth based on HSI2C modules version.

Signed-off-by: Naveen Krishna Chatradhi 
[For finding out the difference and initial contribution]
Signed-off-by: Pankaj Dubey 
---
Changes since v1:
Added missed out Signed-off-by line for initial contribution
Also rebasing on linux-i2c for-next

 drivers/i2c/busses/i2c-exynos5.c |   29 ++---
 1 file changed, 18 insertions(+), 11 deletions(-)

diff --git a/drivers/i2c/busses/i2c-exynos5.c b/drivers/i2c/busses/i2c-exynos5.c
index 497ff91..a3fdcd8 100644
--- a/drivers/i2c/busses/i2c-exynos5.c
+++ b/drivers/i2c/busses/i2c-exynos5.c
@@ -77,12 +77,6 @@
 #define HSI2C_RXFIFO_TRIGGER_LEVEL(x)  ((x) << 4)
 #define HSI2C_TXFIFO_TRIGGER_LEVEL(x)  ((x) << 16)
 
-/* As per user manual FIFO max depth is 64bytes */
-#define HSI2C_FIFO_MAX 0x40
-/* default trigger levels for Tx and Rx FIFOs */
-#define HSI2C_DEF_TXFIFO_LVL   (HSI2C_FIFO_MAX - 0x30)
-#define HSI2C_DEF_RXFIFO_LVL   (HSI2C_FIFO_MAX - 0x10)
-
 /* I2C_TRAILING_CTL Register bits */
 #define HSI2C_TRAILING_COUNT   (0xf)
 
@@ -187,6 +181,9 @@ struct exynos5_i2c {
 
/* Version of HS-I2C Hardware */
unsigned intversion;
+
+   /* FIFO depth */
+   unsigned intfifo_depth;
 };
 
 enum hsi2c_version {
@@ -437,7 +434,7 @@ static irqreturn_t exynos5_i2c_irq(int irqno, void *dev_id)
fifo_status = readl(i2c->regs + HSI2C_FIFO_STATUS);
fifo_level = HSI2C_TX_FIFO_LVL(fifo_status);
 
-   len = HSI2C_FIFO_MAX - fifo_level;
+   len = i2c->fifo_depth - fifo_level;
if (len > (i2c->msg->len - i2c->msg_ptr))
len = i2c->msg->len - i2c->msg_ptr;
 
@@ -505,6 +502,7 @@ static void exynos5_i2c_message_start(struct exynos5_i2c 
*i2c, int stop)
u32 i2c_auto_conf = 0;
u32 fifo_ctl;
unsigned long flags;
+   unsigned short trig_lvl;
 
i2c_ctl = readl(i2c->regs + HSI2C_CTL);
i2c_ctl &= ~(HSI2C_TXCHON | HSI2C_RXCHON);
@@ -515,13 +513,19 @@ static void exynos5_i2c_message_start(struct exynos5_i2c 
*i2c, int stop)
 
i2c_auto_conf = HSI2C_READ_WRITE;
 
-   fifo_ctl |= HSI2C_RXFIFO_TRIGGER_LEVEL(HSI2C_DEF_TXFIFO_LVL);
+   trig_lvl = (i2c->msg->len > i2c->fifo_depth) ?
+   (i2c->fifo_depth * 3/4) : i2c->msg->len;
+   fifo_ctl |= HSI2C_RXFIFO_TRIGGER_LEVEL(trig_lvl);
+
int_en |= (HSI2C_INT_RX_ALMOSTFULL_EN |
HSI2C_INT_TRAILING_EN);
} else {
i2c_ctl |= HSI2C_TXCHON;
 
-   fifo_ctl |= HSI2C_TXFIFO_TRIGGER_LEVEL(HSI2C_DEF_RXFIFO_LVL);
+   trig_lvl = (i2c->msg->len > i2c->fifo_depth) ?
+   (i2c->fifo_depth * 1/4) : i2c->msg->len;
+   fifo_ctl |= HSI2C_TXFIFO_TRIGGER_LEVEL(trig_lvl);
+
int_en |= HSI2C_INT_TX_ALMOSTEMPTY_EN;
}
 
@@ -716,10 +720,13 @@ static int exynos5_i2c_probe(struct platform_device *pdev)
i2c->version = exynos5_i2c_get_version(pdev);
 
/* The HS-I2C core on Exynos5260 needs a reset to start with */
-   if (i2c->version == EXYNOS_5260)
+   if (i2c->version == EXYNOS_5260) {
+   i2c->fifo_depth = 16;
exynos5_i2c_reset(i2c);
-   else
+   } else {
+   i2c->fifo_depth = 64;
exynos5_i2c_init(i2c);
+   }
 
ret = i2c_add_adapter(>adap);
if (ret < 0) {
-- 
1.7.10.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/2 v2] i2c: exynos5: add support for HSI2C on Exynos5260 SoC

[Naveen Krishna Chatradhi]

This patch adds new compatible to support HSI2C module on Exynos5260
HSI2C module on Exynos5260 needs to be reset during during initialization.

Signed-off-by: Naveen Krishna Chatradhi 
---
Changes since v1:
Rebasing on linux-i2c for-next

 .../devicetree/bindings/i2c/i2c-exynos5.txt|6 +++-
 drivers/i2c/busses/i2c-exynos5.c   |   31 ++--
 2 files changed, 34 insertions(+), 3 deletions(-)

diff --git a/Documentation/devicetree/bindings/i2c/i2c-exynos5.txt 
b/Documentation/devicetree/bindings/i2c/i2c-exynos5.txt
index 056732c..704ab92 100644
--- a/Documentation/devicetree/bindings/i2c/i2c-exynos5.txt
+++ b/Documentation/devicetree/bindings/i2c/i2c-exynos5.txt
@@ -5,7 +5,11 @@ at various speeds ranging from 100khz to 3.4Mhz.
 
 Required properties:
   - compatible: value should be.
-  -> "samsung,exynos5-hsi2c", for i2c compatible with exynos5 hsi2c.
+   -> "samsung,exynos5-hsi2c", for i2c compatible with HSI2C available on
+   Exynos5250/5420 SoCs.
+   -> "samsung,exynos5260-hsi2c", for i2c compatible with HSI2C available
+   on Exynos5260 SoCs.
+
   - reg: physical base address of the controller and length of memory mapped
 region.
   - interrupts: interrupt number to the cpu.
diff --git a/drivers/i2c/busses/i2c-exynos5.c b/drivers/i2c/busses/i2c-exynos5.c
index da39ff0..497ff91 100644
--- a/drivers/i2c/busses/i2c-exynos5.c
+++ b/drivers/i2c/busses/i2c-exynos5.c
@@ -184,14 +184,35 @@ struct exynos5_i2c {
 * 2. Fast speed upto 1Mbps
 */
int speed_mode;
+
+   /* Version of HS-I2C Hardware */
+   unsigned intversion;
+};
+
+enum hsi2c_version {
+   EXYNOS_5,
+   EXYNOS_5260
 };
 
 static const struct of_device_id exynos5_i2c_match[] = {
-   { .compatible = "samsung,exynos5-hsi2c" },
+   {
+   .compatible = "samsung,exynos5-hsi2c",
+   .data = (void *)EXYNOS_5 },
+   {
+   .compatible = "samsung,exynos5260-hsi2c",
+   .data = (void *)EXYNOS_5260 },
{},
 };
 MODULE_DEVICE_TABLE(of, exynos5_i2c_match);
 
+static inline unsigned int exynos5_i2c_get_version(struct platform_device 
*pdev)
+{
+   const struct of_device_id *match;
+
+   match = of_match_node(exynos5_i2c_match, pdev->dev.of_node);
+   return (unsigned int)match->data;
+}
+
 static void exynos5_i2c_clr_pend_irq(struct exynos5_i2c *i2c)
 {
writel(readl(i2c->regs + HSI2C_INT_STATUS),
@@ -692,7 +713,13 @@ static int exynos5_i2c_probe(struct platform_device *pdev)
if (ret)
goto err_clk;
 
-   exynos5_i2c_init(i2c);
+   i2c->version = exynos5_i2c_get_version(pdev);
+
+   /* The HS-I2C core on Exynos5260 needs a reset to start with */
+   if (i2c->version == EXYNOS_5260)
+   exynos5_i2c_reset(i2c);
+   else
+   exynos5_i2c_init(i2c);
 
ret = i2c_add_adapter(>adap);
if (ret < 0) {
-- 
1.7.10.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v4] i2c: s3c2410: dont need CPU_FREQ transitions for exynos series

[Naveen Krishna Chatradhi]

For Exynos4 and Exynos5 SoCs from Samsung the i2c clock is based
on a fixed 66 MHz peripheral clock, and therefore is completely
independent of the cpu frequency.
Thus, registering for a CPU freq notifier is very wasteful.

This patch modifes the code such that, i2c bus registers to
cpu_freq_transition only if CONFIG_CPU_FREQ_S3C24XX is enabled.

This change should save a bunch of cpufreq transitions calls
which does not apply to exynos SoCs.

Signed-off-by: Naveen Krishna Chatradhi 
Acked-by: Kyungmin Park 
Reviewed-by: Doug Anderson 
---
Changes since v3:
As per discussion at https://patchwork.kernel.org/patch/3235091/
Post f023f8dd59 commit we should be using
ARM_S3C24XX_CPUFREQ instead of CPU_FREQ_S3C24XX

upstrea linux kernel and linuxsamsung already has the commit
f023f8dd59. Hence, rebasing the patch.

 drivers/i2c/busses/i2c-s3c2410.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/i2c/busses/i2c-s3c2410.c b/drivers/i2c/busses/i2c-s3c2410.c
index bf8fb94..a77ce13 100644
--- a/drivers/i2c/busses/i2c-s3c2410.c
+++ b/drivers/i2c/busses/i2c-s3c2410.c
@@ -123,7 +123,7 @@ struct s3c24xx_i2c {
struct s3c2410_platform_i2c *pdata;
int gpios[2];
struct pinctrl  *pctrl;
-#ifdef CONFIG_CPU_FREQ
+#if defined(CONFIG_ARM_S3C24XX_CPUFREQ)
struct notifier_block   freq_transition;
 #endif
 };
@@ -843,7 +843,7 @@ static int s3c24xx_i2c_clockrate(struct s3c24xx_i2c *i2c, 
unsigned int *got)
return 0;
 }
 
-#ifdef CONFIG_CPU_FREQ
+#if defined(CONFIG_ARM_S3C24XX_CPUFREQ)
 
 #define freq_to_i2c(_n) container_of(_n, struct s3c24xx_i2c, freq_transition)
 
-- 
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] PCI: add a quirk for keeping Bus Master bit on shutdown

[Bjorn Helgaas]

On Mon, Nov 25, 2013 at 9:11 PM, Chang Liu  wrote:
> If this turns out to be a problem specific to Acer V573G, we can simply
> wrap the if (pdev->...) line in ata/ahci.c with if
> (dmi_check_system(acer_v573g))
> so that only acer v573g laptops will be affected by this patch. The remaining
> part of the patch won't need to be changed.

Well, sure.  But that doesn't change the fact that until we know *why*
it hangs, this is voodoo programming.  And I don't like voodoo
programming.

> 2013/11/26 Bjorn Helgaas :
>> [+cc Lan, Khalid, Konstantin, Alan, Takao, Jility, Florian, linux-kernel]
>>
>> On Tue, Nov 12, 2013 at 07:40:03PM +, Chang Liu wrote:
>>> This fixes https://bugzilla.kernel.org/show_bug.cgi?id=63861
>>>
>>> Commit b566a22c2 and 7897e60227 made pci_device_shutdown()
>>> unconditionally clear Bus Master bit for every pci devices.
>>> While this works for most hardware, certain devices are not
>>> compatible with this. Intel Lynx Point-LP SATA Controller,
>>> for example, will hang the system if its Bus Master bit is
>>> cleared during device shutdown. This patch adds a pci quirk
>>> so that device drivers can instruct pci_device_shutdown()
>>> to keep Bus Master from being cleared, and then implements
>>> this mechanism for the Intel Lynx Point-LP AHCI driver.
>>>
>>> Signed-off-by: Chang Liu 
>>
>> I'm not 100% comfortable with disabling bus mastering in general;
>> see [1] for more details.
>>
>> But given that we have been doing it for quite a while (b566a22c2 appeared
>> in v3.5 on Jul 21, 2012), and Lynx Point should be in lots of machines, I'm
>> surprised that we don't see more reports of this problem if it really
>> affects all Lynx Point parts.
>>
>> Jility reported the same problem [2], and I did find one other similar
>> report [3] from Florian.  All three reports (Chang, Jility, Florian) are on
>> the same exact machine (Acer V5-573G), which seems sort of suspicious.
>>
>> Lan, do you have access to any Lynx Point boxes?  Can you test and see
>> whether they hang on power-off also?  I suspect this might be something
>> specific to the Acer box, not a generic Lynx Point issue.
>>
>> Bjorn
>>
>> [1] http://lkml.kernel.org/r/20120427190033.ga17...@ldl.usa.hp.com
>> [2] https://bugzilla.kernel.org/show_bug.cgi?id=63861#c21
>> [3] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1249329
>>
>>> ---
>>> As per Takao's suggestion, add a new member into struct pci_dev
>>> and add a quirk in the ahci driver. I tested this on my
>>> machine (Acer V5-573G) and it works fine.
>>>
>>>  drivers/ata/ahci.c   |  8 
>>>  drivers/pci/pci-driver.c | 11 ---
>>>  include/linux/pci.h  |  1 +
>>>  3 files changed, 17 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c
>>> index 8e28f92..de6efcb 100644
>>> --- a/drivers/ata/ahci.c
>>> +++ b/drivers/ata/ahci.c
>>> @@ -1385,6 +1385,14 @@ static int ahci_init_one(struct pci_dev *pdev, const 
>>> struct pci_device_id *ent)
>>>
>>>   pci_set_master(pdev);
>>>
>>> + /* We normally clear Bus Master on pci device shutdown. However,
>>> + * doing so for Intel Lynx Point-LP SATA Controller [AHCI mode]
>>> + * hangs the system. Therefore keep it.
>>> + * See bug report: https://bugzilla.kernel.org/show_bug.cgi?id=63861
>>> + */
>>> + if (pdev->vendor == PCI_VENDOR_ID_INTEL && pdev->device == 0x9c03)
>>> + pdev->keep_busmaster_on_shutdown = 1;
>>> +
>>>   if (hpriv->flags & AHCI_HFLAG_MULTI_MSI)
>>>   return ahci_host_activate(host, pdev->irq, n_msis);
>>>
>>> diff --git a/drivers/pci/pci-driver.c b/drivers/pci/pci-driver.c
>>> index 38f3c01..ff15b0c 100644
>>> --- a/drivers/pci/pci-driver.c
>>> +++ b/drivers/pci/pci-driver.c
>>> @@ -392,10 +392,15 @@ static void pci_device_shutdown(struct device *dev)
>>>   pci_msix_shutdown(pci_dev);
>>>
>>>   /*
>>> - * Turn off Bus Master bit on the device to tell it to not
>>> - * continue to do DMA. Don't touch devices in D3cold or unknown states.
>>> + * If the hardware is okay with it, turn off Bus Master bit
>>> + * on the device to tell it not to continue doing DMA.
>>> + * Don't touch devices in D3cold or unknown states.
>>> + * On certain hardware clearing Bus Master bit on shutdown
>>> + * may hang the entire system. In these cases the driver of
>>> + * these devices should set keep_busmaster_on_shutdown to 1.
>>>   */
>>> - if (pci_dev->current_state <= PCI_D3hot)
>>> + if (!pci_dev->keep_busmaster_on_shutdown
>>> +&& pci_dev->current_state <= PCI_D3hot)
>>>   pci_clear_master(pci_dev);
>>>  }
>>>
>>> diff --git a/include/linux/pci.h b/include/linux/pci.h
>>> index da172f9..63db735 100644
>>> --- a/include/linux/pci.h
>>> +++ b/include/linux/pci.h
>>> @@ -322,6 +322,7 @@ struct pci_dev {
>>>   /* keep track of device state */
>>>   unsigned int is_added:1;
>>>   unsigned int is_busmaster:1; /* device is busmaster */
>>> + unsigned int keep_busmaster_on_shutdown:1; /* do not clear busmaster on 
>>> shutdown */
>>>   unsigned int no_msi:1; /* device may 

Re: [PATCH] use -fstack-protector-strong

[Nicolas Pitre]

On Mon, 25 Nov 2013, Kees Cook wrote:

> On Mon, Nov 25, 2013 at 3:16 PM, H. Peter Anvin  wrote:
> > On 11/25/2013 02:14 PM, Kees Cook wrote:
> >> Build the kernel with -fstack-protector-strong when it is available
> >> (gcc 4.9 and later). This increases the coverage of the stack protector
> >> without the heavy performance hit of -fstack-protector-all.
> >
> > What is the difference between the various options?
> 
> -fstack-protector-all:
> Adds the stack-canary saving prefix and stack-canary checking suffix
> to _all_ function entry and exit. Results in substantial use of stack
> space for saving the canary for deep stack users (e.g. historically
> xfs), and measurable (though shockingly still low) performance hit due
> to all the saving/checking. Really not suitable for sane systems, and
> was entirely removed as an option from the kernel many years ago.
> 
> -fstack-protector:
> Adds the canary save/check to functions that define an 8
> (--param=ssp-buffer-size=N, N=8 by default) or more byte local char
> array. Traditionally, stack overflows happened with string-based
> manipulations, so this was a way to find those functions. Very few
> total functions actually get the canary; no measurable performance or
> size overhead.
> 
> -fstack-protector-strong
> Adds the canary for a wider set of functions, since it's not just
> those with strings that have ultimately been vulnerable to
> stack-busting. With this superset, more functions end up with a
> canary, but it still remains small compared to all functions with no
> measurable change in performance. Based on the original design
> document, a function gets the canary when it contains any of:
> - local variable's address used as part of the RHS of an assignment or
> function argument
> - local variable is an array (or union containing an array),
> regardless of array type or length
> - uses register local variables
> https://docs.google.com/a/google.com/document/d/1xXBH6rRZue4f296vGt9YQcuLVQHeE516stHwt8M9xyU
> 
> Chrome OS has been using -fstack-protector-strong for its kernel
> builds for the last 8 months with no problems.

Could you get this information inside the commit log for your patch 
please?  This is very valuable info to have right next to the change in 
the repository without having to dig into the gcc manual or finding the 
relevant email thread.


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 v2 09/10] PCI: Sort pci root bus resources list

[Bjorn Helgaas]

On Mon, Nov 25, 2013 at 6:28 PM, Yinghai Lu  wrote:
> Some x86 systems expose above 4G 64bit mmio in _CRS as non-pref mmio range.
> [   49.415281] PCI host bridge to bus :00
> [   49.419921] pci_bus :00: root bus resource [bus 00-1e]
> [   49.426107] pci_bus :00: root bus resource [io  0x-0x0cf7]
> [   49.433041] pci_bus :00: root bus resource [io  0x1000-0x5fff]
> [   49.440010] pci_bus :00: root bus resource [mem 0x000a-0x000b]
> [   49.447768] pci_bus :00: root bus resource [mem 0xfed8c000-0xfedf]
> [   49.455532] pci_bus :00: root bus resource [mem 0x9000-0x9fffbfff]
> [   49.463259] pci_bus :00: root bus resource [mem 
> 0x3800-0x381f]
>
> During assign unassigned 64bit mmio resource, it will go through
> every non-pref mmio for root bus in pci_bus_alloc_resource().
> As the loop is with pci_bus_for_each_resource(), and could have chance
> to use under 4G mmio range instead of above 4G mmio range if the requested
> range is not big enough, even it could handle above 4G 64bit pref mmio.
>
> For root bus, we can order list from high to low in pci_add_resource_offset(),
> during creating root bus, it will still keep the same order in final bus
> resource list.
> pci_acpi_scan_root
> ==> add_resources
> ==> pci_add_resource_offset: # Add to temp resources
> ==> pci_create_root_bus
> ==> pci_bus_add_resource # add to final bus resources.
>
> After that, we can make sure 64bit pref mmio for pci bridges will be allocated
> higest of mmio non-pref, and in this case it is above 4G instead of under 4G.

Sorry I'm so slow; I'd like to know what problem this solves, too.
I'm trying to help people at distros figure out whether they will need
to backport this change.

> Signed-off-by: Yinghai Lu 
> ---
>  drivers/pci/bus.c | 15 +--
>  1 file changed, 13 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/pci/bus.c b/drivers/pci/bus.c
> index f801f6a..adf17858 100644
> --- a/drivers/pci/bus.c
> +++ b/drivers/pci/bus.c
> @@ -21,7 +21,8 @@
>  void pci_add_resource_offset(struct list_head *resources, struct resource 
> *res,
>  resource_size_t offset)
>  {
> -   struct pci_host_bridge_window *window;
> +   struct pci_host_bridge_window *window, *tmp;
> +   struct list_head *n;
>
> window = kzalloc(sizeof(struct pci_host_bridge_window), GFP_KERNEL);
> if (!window) {
> @@ -31,7 +32,17 @@ void pci_add_resource_offset(struct list_head *resources, 
> struct resource *res,
>
> window->res = res;
> window->offset = offset;
> -   list_add_tail(>list, resources);
> +
> +   /* sorted it according to res end */
> +   n = resources;
> +   list_for_each_entry(tmp, resources, list)
> +   if (window->res->end > tmp->res->end) {
> +   n = >list;
> +   break;
> +   }
> +
> +   /* Insert it just before n */
> +   list_add_tail(>list, n);
>  }
>  EXPORT_SYMBOL(pci_add_resource_offset);
>
> --
> 1.8.1.4
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 08/10] PCI: Try best to allocate pref mmio 64bit above 4g

[Bjorn Helgaas]

On Mon, Nov 25, 2013 at 6:28 PM, Yinghai Lu  wrote:
> When one of children resources does not support MEM_64, MEM_64 for
> bridge get reset, so pull down whole pref resource on the bridge under 4G.
>
> If the bridge support pref mem 64, will only allocate that with pref mem64 to
> children that support it.
> For children resources if they only support pref mem 32, will allocate them
> from non pref mem instead.
>
> If the bridge only support 32bit pref mmio, will still have all children pref
> mmio under that.

I can't figure out if this is supposed to fix a problem, and if so,
what problem it is.  Can you include a URL for a bugzilla or other
problem description?

> -v2: Add release bridge res support with bridge mem res for pref_mem children 
> res.
> -v3: refresh and make it can be applied early before for_each_dev_res 
> patchset.
>
> Signed-off-by: Yinghai Lu 
> Tested-by: Guo Chao 
> ---
>  drivers/pci/setup-bus.c | 133 
> 
>  drivers/pci/setup-res.c |  14 -
>  2 files changed, 101 insertions(+), 46 deletions(-)
>
> diff --git a/drivers/pci/setup-bus.c b/drivers/pci/setup-bus.c
> index 219a410..b98419e 100644
> --- a/drivers/pci/setup-bus.c
> +++ b/drivers/pci/setup-bus.c
> @@ -711,12 +711,11 @@ static void pci_bridge_check_ranges(struct pci_bus *bus)
> bus resource of a given type. Note: we intentionally skip
> the bus resources which have already been assigned (that is,
> have non-NULL parent resource). */
> -static struct resource *find_free_bus_resource(struct pci_bus *bus, unsigned 
> long type)
> +static struct resource *find_free_bus_resource(struct pci_bus *bus,
> +unsigned long type_mask, unsigned long type)
>  {
> int i;
> struct resource *r;
> -   unsigned long type_mask = IORESOURCE_IO | IORESOURCE_MEM |
> - IORESOURCE_PREFETCH;
>
> pci_bus_for_each_resource(bus, r, i) {
> if (r == _resource || r == _resource)
> @@ -813,7 +812,8 @@ static void pbus_size_io(struct pci_bus *bus, 
> resource_size_t min_size,
> resource_size_t add_size, struct list_head *realloc_head)
>  {
> struct pci_dev *dev;
> -   struct resource *b_res = find_free_bus_resource(bus, IORESOURCE_IO);
> +   struct resource *b_res = find_free_bus_resource(bus, IORESOURCE_IO,
> +   IORESOURCE_IO);
> resource_size_t size = 0, size0 = 0, size1 = 0;
> resource_size_t children_add_size = 0;
> resource_size_t min_align, align;
> @@ -913,15 +913,16 @@ static inline resource_size_t 
> calculate_mem_align(resource_size_t *aligns,
>   * guarantees that all child resources fit in this size.
>   */
>  static int pbus_size_mem(struct pci_bus *bus, unsigned long mask,
> -unsigned long type, resource_size_t min_size,
> -   resource_size_t add_size,
> -   struct list_head *realloc_head)
> +unsigned long type, unsigned long type2,
> +resource_size_t min_size, resource_size_t add_size,
> +struct list_head *realloc_head)
>  {
> struct pci_dev *dev;
> resource_size_t min_align, align, size, size0, size1;
> resource_size_t aligns[12]; /* Alignments from 1Mb to 2Gb */
> int order, max_order;
> -   struct resource *b_res = find_free_bus_resource(bus, type);
> +   struct resource *b_res = find_free_bus_resource(bus,
> +mask | IORESOURCE_PREFETCH, type);
> unsigned int mem64_mask = 0;
> resource_size_t children_add_size = 0;
>
> @@ -942,7 +943,8 @@ static int pbus_size_mem(struct pci_bus *bus, unsigned 
> long mask,
> struct resource *r = >resource[i];
> resource_size_t r_size;
>
> -   if (r->parent || (r->flags & mask) != type)
> +   if (r->parent || ((r->flags & mask) != type &&
> + (r->flags & mask) != type2))
> continue;
> r_size = resource_size(r);
>  #ifdef CONFIG_PCI_IOV
> @@ -1115,8 +1117,9 @@ void __ref __pci_bus_size_bridges(struct pci_bus *bus,
> struct list_head *realloc_head)
>  {
> struct pci_dev *dev;
> -   unsigned long mask, prefmask;
> +   unsigned long mask, prefmask, type2 = 0;
> resource_size_t additional_mem_size = 0, additional_io_size = 0;
> +   struct resource *b_res;
>
> list_for_each_entry(dev, >devices, bus_list) {
> struct pci_bus *b = dev->subordinate;
> @@ -1161,15 +1164,31 @@ void __ref __pci_bus_size_bridges(struct pci_bus *bus,
>has already been allocated by arch code, try
>non-prefetchable range for both types of PCI 

Re: [PATCH v2 07/10] PCI: Try to allocate mem64 above 4G at first

[Bjorn Helgaas]

On Mon, Nov 25, 2013 at 6:28 PM, Yinghai Lu  wrote:
> Will fall back to below 4g if it can not find any above 4g.

Does this fix a bug?  If so, please include a bugzilla or mailing list URL.

> x86 32bit without X86_PAE support will have bottom set to 0, because
> resource_size_t is 32bit.
>
> Also for 32bit with resource_size_t 64bit kernel on machine with pae support
> we are safe because iomem_resource is limited to 32bit according to
> x86_phys_bits.
>
> -v2: update bottom assigning to make it clear for non-pae support machine.
> -v3: Bjorn's change:
> use MAX_RESOURCE instead of -1
> use start/end instead of bottom/max
> for all arch instead of just x86_64
> -v4: updated after PCI_MAX_RESOURCE_32 change.
> -v5: restore io handling to use PCI_MAX_RESOURCE_32 as limit.
> -v6: checking pcibios_resource_to_bus return for every bus res, to decide it
> if we need to try high at first.
>  It supports all arches instead of just x86_64.
>
> Signed-off-by: Yinghai Lu 
> ---
>  arch/x86/include/asm/pci.h |  1 -
>  drivers/pci/bus.c  | 42 ++
>  drivers/pci/pci.h  |  2 ++
>  include/linux/pci.h|  4 
>  4 files changed, 36 insertions(+), 13 deletions(-)
>
> diff --git a/arch/x86/include/asm/pci.h b/arch/x86/include/asm/pci.h
> index 947b5c4..122c299 100644
> --- a/arch/x86/include/asm/pci.h
> +++ b/arch/x86/include/asm/pci.h
> @@ -125,7 +125,6 @@ int setup_msi_irq(struct pci_dev *dev, struct msi_desc 
> *msidesc,
>
>  /* generic pci stuff */
>  #include 
> -#define PCIBIOS_MAX_MEM_32 0x
>
>  #ifdef CONFIG_NUMA
>  /* Returns the node based on pci bus */
> diff --git a/drivers/pci/bus.c b/drivers/pci/bus.c
> index 1ffd95b..f801f6a 100644
> --- a/drivers/pci/bus.c
> +++ b/drivers/pci/bus.c
> @@ -125,15 +125,13 @@ pci_bus_alloc_resource(struct pci_bus *bus, struct 
> resource *res,
>  {
> int i, ret = -ENOMEM;
> struct resource *r;
> -   resource_size_t max = -1;
>
> type_mask |= IORESOURCE_IO | IORESOURCE_MEM;
>
> -   /* don't allocate too high if the pref mem doesn't support 64bit*/
> -   if (!(res->flags & IORESOURCE_MEM_64))
> -   max = PCIBIOS_MAX_MEM_32;
> -
> pci_bus_for_each_resource(bus, r, i) {
> +   resource_size_t start, end, middle;
> +   struct pci_bus_region region;
> +

I think you're doing two things at once in this patch:

1) Fixing the problem that the IORESOURCE_MEM_64 constraint was being
applied to CPU addresses, not bus addresses, and

2) Trying to allocate above 4G first.

Please separate these into two patches.  The first thing is an obvious
problem and should have little risk of breaking anything.  The second
probably makes sense, but the allocation change could certainly break
something and have to be reverted.  It would be good if we could save
the first fix if that happened.

> if (!r)
> continue;
>
> @@ -147,14 +145,42 @@ pci_bus_alloc_resource(struct pci_bus *bus, struct 
> resource *res,
> !(res->flags & IORESOURCE_PREFETCH))
> continue;
>
> +   start = 0;
> +   end = MAX_RESOURCE;
> +   /*
> +* don't allocate too high if the pref mem doesn't
> +* support 64bit, also if this is a 64-bit mem
> +* resource, try above 4GB first
> +*/
> +   __pcibios_resource_to_bus(bus, , r);
> +   if (region.start <= PCI_MAX_ADDR_32 &&
> +   region.end > PCI_MAX_ADDR_32) {
> +   middle = pcibios_bus_addr_to_res(bus, res->flags,
> + PCI_MAX_ADDR_32);
> +   if (res->flags & IORESOURCE_MEM_64)
> +   start = middle + 1;
> +   else
> +   end = middle;
> +   } else if (region.start > PCI_MAX_ADDR_32 &&
> +  !(res->flags & IORESOURCE_MEM_64))
> +   continue;

This is sort of ugly.  Can you make some sort of "pci_clip_resource()"
 so this loop remains readable?  E.g., something like:

  static pci_bus_region pci_mem_32 = { 0, 0x };
  static pci_bus_region pci_mem_64 = { 0x1, 0x };

  struct resource avail = *r;

  if (res->flags & IORESOURCE_MEM_64)
pci_clip_resource(, _mem_64);
  else
pci_clip_resource(, _mem_32);
  if (!resource_size())
continue;

> +
> +again:
> /* Ok, try it out.. */
> ret = allocate_resource(r, res, size,
> -   r->start ? : min,
> -   max, align,
> +   max(start, r->start ? : min),
> +   end, align,
> 

Re: [PATCH V3 1/6] cpufreq: suspend governors on system suspend/hibernate

[viresh kumar]

On Monday 25 November 2013 07:41 PM, Viresh Kumar wrote:
> diff --git a/include/linux/cpufreq.h b/include/linux/cpufreq.h
> index dc196bb..6d93f91 100644
> --- a/include/linux/cpufreq.h
> +++ b/include/linux/cpufreq.h
> @@ -255,6 +255,9 @@ struct cpufreq_driver {
>  int cpufreq_register_driver(struct cpufreq_driver *driver_data);
>  int cpufreq_unregister_driver(struct cpufreq_driver *driver_data);
>  
> +void cpufreq_suspend(void);
> +void cpufreq_resume(void);
> +
>  const char *cpufreq_get_current_driver(void);
>  
>  static inline void cpufreq_verify_within_limits(struct cpufreq_policy 
> *policy,

A minor fix here to get kernel compiled without cpufreq support enabled:

diff --git a/include/linux/cpufreq.h b/include/linux/cpufreq.h
index 8d8b2f4..d40809d 100644
--- a/include/linux/cpufreq.h
+++ b/include/linux/cpufreq.h
@@ -259,9 +259,6 @@ struct cpufreq_driver {
 int cpufreq_register_driver(struct cpufreq_driver *driver_data);
 int cpufreq_unregister_driver(struct cpufreq_driver *driver_data);

-void cpufreq_suspend(void);
-void cpufreq_resume(void);
-
 const char *cpufreq_get_current_driver(void);

 static inline void cpufreq_verify_within_limits(struct cpufreq_policy *policy,
@@ -287,6 +284,14 @@ cpufreq_verify_within_cpu_limits(struct cpufreq_policy 
*policy)
policy->cpuinfo.max_freq);
 }

+#ifdef CONFIG_CPU_FREQ
+void cpufreq_suspend(void);
+void cpufreq_resume(void);
+#elif
+static inline void cpufreq_suspend(void) {}
+static inline void cpufreq_resume(void) {}
+#endif
+
 /*
  * CPUFREQ NOTIFIER INTERFACE*
  */
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] PCI: add a quirk for keeping Bus Master bit on shutdown

[Chang Liu]

If this turns out to be a problem specific to Acer V573G, we can simply
wrap the if (pdev->...) line in ata/ahci.c with if
(dmi_check_system(acer_v573g))
so that only acer v573g laptops will be affected by this patch. The remaining
part of the patch won't need to be changed.

I can do an updated one as soon as it is confirmed that this is an acer specific
issue.

2013/11/26 Bjorn Helgaas :
> [+cc Lan, Khalid, Konstantin, Alan, Takao, Jility, Florian, linux-kernel]
>
> On Tue, Nov 12, 2013 at 07:40:03PM +, Chang Liu wrote:
>> This fixes https://bugzilla.kernel.org/show_bug.cgi?id=63861
>>
>> Commit b566a22c2 and 7897e60227 made pci_device_shutdown()
>> unconditionally clear Bus Master bit for every pci devices.
>> While this works for most hardware, certain devices are not
>> compatible with this. Intel Lynx Point-LP SATA Controller,
>> for example, will hang the system if its Bus Master bit is
>> cleared during device shutdown. This patch adds a pci quirk
>> so that device drivers can instruct pci_device_shutdown()
>> to keep Bus Master from being cleared, and then implements
>> this mechanism for the Intel Lynx Point-LP AHCI driver.
>>
>> Signed-off-by: Chang Liu 
>
> I'm not 100% comfortable with disabling bus mastering in general;
> see [1] for more details.
>
> But given that we have been doing it for quite a while (b566a22c2 appeared
> in v3.5 on Jul 21, 2012), and Lynx Point should be in lots of machines, I'm
> surprised that we don't see more reports of this problem if it really
> affects all Lynx Point parts.
>
> Jility reported the same problem [2], and I did find one other similar
> report [3] from Florian.  All three reports (Chang, Jility, Florian) are on
> the same exact machine (Acer V5-573G), which seems sort of suspicious.
>
> Lan, do you have access to any Lynx Point boxes?  Can you test and see
> whether they hang on power-off also?  I suspect this might be something
> specific to the Acer box, not a generic Lynx Point issue.
>
> Bjorn
>
> [1] http://lkml.kernel.org/r/20120427190033.ga17...@ldl.usa.hp.com
> [2] https://bugzilla.kernel.org/show_bug.cgi?id=63861#c21
> [3] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1249329
>
>> ---
>> As per Takao's suggestion, add a new member into struct pci_dev
>> and add a quirk in the ahci driver. I tested this on my
>> machine (Acer V5-573G) and it works fine.
>>
>>  drivers/ata/ahci.c   |  8 
>>  drivers/pci/pci-driver.c | 11 ---
>>  include/linux/pci.h  |  1 +
>>  3 files changed, 17 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c
>> index 8e28f92..de6efcb 100644
>> --- a/drivers/ata/ahci.c
>> +++ b/drivers/ata/ahci.c
>> @@ -1385,6 +1385,14 @@ static int ahci_init_one(struct pci_dev *pdev, const 
>> struct pci_device_id *ent)
>>
>>   pci_set_master(pdev);
>>
>> + /* We normally clear Bus Master on pci device shutdown. However,
>> + * doing so for Intel Lynx Point-LP SATA Controller [AHCI mode]
>> + * hangs the system. Therefore keep it.
>> + * See bug report: https://bugzilla.kernel.org/show_bug.cgi?id=63861
>> + */
>> + if (pdev->vendor == PCI_VENDOR_ID_INTEL && pdev->device == 0x9c03)
>> + pdev->keep_busmaster_on_shutdown = 1;
>> +
>>   if (hpriv->flags & AHCI_HFLAG_MULTI_MSI)
>>   return ahci_host_activate(host, pdev->irq, n_msis);
>>
>> diff --git a/drivers/pci/pci-driver.c b/drivers/pci/pci-driver.c
>> index 38f3c01..ff15b0c 100644
>> --- a/drivers/pci/pci-driver.c
>> +++ b/drivers/pci/pci-driver.c
>> @@ -392,10 +392,15 @@ static void pci_device_shutdown(struct device *dev)
>>   pci_msix_shutdown(pci_dev);
>>
>>   /*
>> - * Turn off Bus Master bit on the device to tell it to not
>> - * continue to do DMA. Don't touch devices in D3cold or unknown states.
>> + * If the hardware is okay with it, turn off Bus Master bit
>> + * on the device to tell it not to continue doing DMA.
>> + * Don't touch devices in D3cold or unknown states.
>> + * On certain hardware clearing Bus Master bit on shutdown
>> + * may hang the entire system. In these cases the driver of
>> + * these devices should set keep_busmaster_on_shutdown to 1.
>>   */
>> - if (pci_dev->current_state <= PCI_D3hot)
>> + if (!pci_dev->keep_busmaster_on_shutdown
>> +&& pci_dev->current_state <= PCI_D3hot)
>>   pci_clear_master(pci_dev);
>>  }
>>
>> diff --git a/include/linux/pci.h b/include/linux/pci.h
>> index da172f9..63db735 100644
>> --- a/include/linux/pci.h
>> +++ b/include/linux/pci.h
>> @@ -322,6 +322,7 @@ struct pci_dev {
>>   /* keep track of device state */
>>   unsigned int is_added:1;
>>   unsigned int is_busmaster:1; /* device is busmaster */
>> + unsigned int keep_busmaster_on_shutdown:1; /* do not clear busmaster on 
>> shutdown */
>>   unsigned int no_msi:1; /* device may not use msi */
>>   unsigned int block_cfg_access:1; /* config space access is blocked */
>>   unsigned int broken_parity_status:1; /* Device generates false positive 
>> parity */
>> --
>> 1.8.4.2
>>
>> --
>> To unsubscribe 

Re: [PATCH 08/16] staging/lustre/mdt: HSM coordinator agent interface

[Peng Tao]

On 11/26/2013 11:30 AM, Greg Kroah-Hartman wrote:

On Tue, Nov 26, 2013 at 10:05:02AM +0800, Peng Tao wrote:

From: JC Lafoucriere 

To move data with external storage, HSM coordinator
uses a Copy Tool running on a client named agent.
This patch implements the interface for these agents.


Interesting text here...


Lustre-change: http://review.whamcloud.com/6534
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-3342
Signed-off-by: JC Lafoucriere 
Reviewed-by: Jinshan Xiong 
Reviewed-by: Andreas Dilger 
Reviewed-by: John L. Hammond 
Reviewed-by: Oleg Drokin 
Signed-off-by: Peng Tao 
Signed-off-by: Andreas Dilger 
---
  .../lustre/lustre/include/lustre/lustre_user.h |6 +++---
  1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/lustre/lustre/include/lustre/lustre_user.h 
b/drivers/staging/lustre/lustre/include/lustre/lustre_user.h
index 9436166..631f026 100644
--- a/drivers/staging/lustre/lustre/include/lustre/lustre_user.h
+++ b/drivers/staging/lustre/lustre/include/lustre/lustre_user.h
@@ -428,8 +428,8 @@ struct obd_uuid {
char uuid[UUID_MAX];
  };

-static inline int obd_uuid_equals(const struct obd_uuid *u1,
- const struct obd_uuid *u2)
+static inline bool obd_uuid_equals(const struct obd_uuid *u1,
+  const struct obd_uuid *u2)
  {
return strcmp((char *)u1->uuid, (char *)u2->uuid) == 0;
  }
@@ -446,7 +446,7 @@ static inline void obd_str2uuid(struct obd_uuid *uuid, 
const char *tmp)
  }

  /* For printf's only, make sure uuid is terminated */
-static inline char *obd_uuid2str(struct obd_uuid *uuid)
+static inline char *obd_uuid2str(const struct obd_uuid *uuid)
  {
if (uuid->uuid[sizeof(*uuid) - 1] != '\0') {
/* Obviously not safe, but for printfs, no real harm done...


Too bad it doesn't describe the changes made in the code at all.

How can so many people review a patch that is not the same as what it
says it really is?

The main part of the original commit is dropped as it only touches 
server code. I should have modified the commit message to say what 
exactly the patch does rather than just copying the original commit 
message. I'll fix up. Sorry.



I'm stopping here in the series, sorry.  Please fix up and resend the
rest when you can.


Will do. Thanks for reviewing!

Thanks,
Tao


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] i2c: s3c2410: dont need CPU_FREQ transitions for exynos series

[Naveen Krishna Ch]

Hello Doug,

On 26 November 2013 05:11, Doug Anderson  wrote:
> Naveen,
>
> On Mon, Nov 18, 2013 at 10:18 PM, Naveen Krishna Chatradhi
>  wrote:
>> For Exynos4 and Exynos5 SoCs from Samsung the i2c clock is based
>> on a fixed 66 MHz peripheral clock, and therefore is completely
>> independent of the cpu frequency.
>> Thus, registering for a CPU freq notifier is very wasteful.
>>
>> This patch modifes the code such that, i2c bus registers to
>> cpu_freq_transition only if CONFIG_CPU_FREQ_S3C24XX is enabled.
>>
>> This change should save a bunch of cpufreq transitions calls
>> which does not apply to exynos SoCs.
>>
>> Signed-off-by: Naveen Krishna Chatradhi 
>> Acked-by: Kyungmin Park 
>> Reviewed-by: Doug Anderson 
>> ---
>> Changes since v2:
>> None, Rebased on for-next of linux-i2c git repo.
>>
>> Changes since v1:
>> Use CONFIG_CPU_FREQ_S3C24XX instead of (CONFIG_CPU_FREQ & !CONFIG_EXYNOS)
>> As commented by Tomasz
>>
>>  drivers/i2c/busses/i2c-s3c2410.c |4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> Can you please spin this with comments from
> ?  Thanks!
Thanks for pointing out for me

To summarize, Post f023f8dd59 commit we should be using
ARM_S3C24XX_CPUFREQ instead of ARM_S3C24XX_CPUFREQ right.

Will re-spin with this changes.
>
> -Doug
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 
> in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



-- 
Thanks & Regards,
(: Nav :)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 02/16] staging/lustre/llog: MGC to use OSD API for backup logs

[Peng Tao]

On 11/26/2013 11:34 AM, Greg Kroah-Hartman wrote:

On Tue, Nov 26, 2013 at 11:25:24AM +0800, Peng Tao wrote:

On Tue, Nov 26, 2013 at 11:14 AM, Greg Kroah-Hartman
 wrote:

On Tue, Nov 26, 2013 at 10:04:56AM +0800, Peng Tao wrote:

From: Mikhail Pershin 

MGC uses lvfs API to access local llogs blocking removal of old code

- MGS is converted to use OSD API for local llogs
- llog_is_empty() and llog_backup() are introduced
- initial OSD start initialize run ctxt so llog can use it too
- shrink dcache after initial scrub in osd-ldiskfs to avoid holding
   data of unlinked objects until umount.


It is not checkpatch clean :(

Come on, it's not hard to do this yourself, why do you make me find
these errors for you?  It does nothing but make me not want to look at
lustre patches for a long time...


Strange. I did run checkpatch before sending the patchset out.

Just tried again. Still pass.

[X61@linux-lustre]$./scripts/checkpatch.pl
0002-staging-lustre-llog-MGC-to-use-OSD-API-for-backup-lo.patch total:
0 errors, 0 warnings, 883 lines checked

0002-staging-lustre-llog-MGC-to-use-OSD-API-for-backup-lo.patch has no
obvious style problems and is ready for submission.

What message did you see?


One about return();

OK. Looks like a latest checkpatch.pl change. After rebasing my working 
copy to latest staging-next, I can see the same error. I'll fix up. 
Sorry for the noise.


Thanks,
Tao




>From 93455fbe9b61a66218225c2ec4c14fc2a86bcf67 Mon Sep 17 00:00:00 2001
From: Mikhail Pershin 
Date: Thu, 31 Oct 2013 17:06:29 +0800
Subject: [PATCH 02/16] staging/lustre/llog: MGC to use OSD API for backup
 logs

MGC uses lvfs API to access local llogs blocking removal of old code

- MGS is converted to use OSD API for local llogs
- llog_is_empty() and llog_backup() are introduced
- initial OSD start initialize run ctxt so llog can use it too
- shrink dcache after initial scrub in osd-ldiskfs to avoid holding
  data of unlinked objects until umount.

Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-2059
Lustre-change: http://review.whamcloud.com/5049
Signed-off-by: Mikhail Pershin 
Reviewed-by: Lai Siyao 
Reviewed-by: Alex Zhuravlev 
Reviewed-by: James Simmons 
Reviewed-by: Oleg Drokin 
Signed-off-by: Peng Tao 
Signed-off-by: Andreas Dilger 
---
 drivers/staging/lustre/lustre/include/dt_object.h  |2 +-
 drivers/staging/lustre/lustre/include/lustre_log.h |   13 +-
 drivers/staging/lustre/lustre/include/obd.h|4 +-
 drivers/staging/lustre/lustre/mgc/libmgc.c |3 -
 drivers/staging/lustre/lustre/mgc/mgc_request.c|  401 
 drivers/staging/lustre/lustre/obdclass/llog.c  |  212 +++
 .../staging/lustre/lustre/obdclass/local_storage.c |9 +-
 .../staging/lustre/lustre/obdclass/local_storage.h |3 +
 drivers/staging/lustre/lustre/obdclass/lu_object.c |2 +-
 drivers/staging/lustre/lustre/obdclass/obd_mount.c |3 +
 10 files changed, 408 insertions(+), 244 deletions(-)

diff --git a/drivers/staging/lustre/lustre/include/dt_object.h b/drivers/staging/lustre/lustre/include/dt_object.h
index e116bb2..9304c26 100644
--- a/drivers/staging/lustre/lustre/include/dt_object.h
+++ b/drivers/staging/lustre/lustre/include/dt_object.h
@@ -692,7 +692,7 @@ struct local_oid_storage {
 	struct dt_object *los_obj;
 
 	/* data used to generate new fids */
-	struct mutex	 los_id_lock;
+	struct mutex	  los_id_lock;
 	__u64		  los_seq;
 	__u32		  los_last_oid;
 };
diff --git a/drivers/staging/lustre/lustre/include/lustre_log.h b/drivers/staging/lustre/lustre/include/lustre_log.h
index 721aa05..896c757 100644
--- a/drivers/staging/lustre/lustre/include/lustre_log.h
+++ b/drivers/staging/lustre/lustre/include/lustre_log.h
@@ -136,7 +136,11 @@ int llog_open(const struct lu_env *env, struct llog_ctxt *ctxt,
 	  struct llog_handle **lgh, struct llog_logid *logid,
 	  char *name, enum llog_open_param open_param);
 int llog_close(const struct lu_env *env, struct llog_handle *cathandle);
-int llog_get_size(struct llog_handle *loghandle);
+int llog_is_empty(const struct lu_env *env, struct llog_ctxt *ctxt,
+		  char *name);
+int llog_backup(const struct lu_env *env, struct obd_device *obd,
+		struct llog_ctxt *ctxt, struct llog_ctxt *bak_ctxt,
+		char *name, char *backup);
 
 /* llog_process flags */
 #define LLOG_FLAG_NODEAMON 0x0001
@@ -382,6 +386,13 @@ static inline int llog_data_len(int len)
 	return cfs_size_round(len);
 }
 
+static inline int llog_get_size(struct llog_handle *loghandle)
+{
+	if (loghandle && loghandle->lgh_hdr)
+		return loghandle->lgh_hdr->llh_count;
+	return 0;
+}
+
 static inline struct llog_ctxt *llog_ctxt_get(struct llog_ctxt *ctxt)
 {
 	atomic_inc(>loc_refcount);
diff --git a/drivers/staging/lustre/lustre/include/obd.h b/drivers/staging/lustre/lustre/include/obd.h
index d0aea15..f0c1773 100644
--- a/drivers/staging/lustre/lustre/include/obd.h
+++ b/drivers/staging/lustre/lustre/include/obd.h
@@ -399,8 +399,8 @@ struct client_obd {
 
 	/* mgc 

Re: [PATCH 3.2 73/87] fs: buffer: move allocation failure loop into the allocator

[Ben Hutchings]

On Mon, 2013-11-25 at 10:13 -0500, Johannes Weiner wrote:
> Hi Ben,
> 
> On Mon, Nov 25, 2013 at 01:44:29PM +, Ben Hutchings wrote:
> > 3.2.53-rc1 review patch.  If anyone has any objections, please let me know.
> > 
> > --
> > 
> > From: Johannes Weiner 
> > 
> > commit 84235de394d9775bfaa7fa9762a59d91fef0c1fc upstream.
> > 
> > Buffer allocation has a very crude indefinite loop around waking the
> > flusher threads and performing global NOFS direct reclaim because it can
> > not handle allocation failures.
> 
> Please don't apply this, it's part of a bigger series and was only
> tagged as a reminder.  I'll send the full series to stable when the
> current cgroup instabilities are ironed out, just to be sure these
> patches are not the problem.

OK, I'll drop this.

Ben.

-- 
Ben Hutchings
Usenet is essentially a HUGE group of people passing notes in class.
  - Rachel Kadel, `A Quick Guide to Newsgroup Etiquette'


signature.asc
Description: This is a digitally signed message part

Re: [PATCH 3.2 63/87] ext4: fix memory leak in xattr

[Ben Hutchings]

On Mon, 2013-11-25 at 14:02 -0500, Dave Jones wrote:
> On Mon, Nov 25, 2013 at 01:44:29PM +, Ben Hutchings wrote:
>  > 3.2.53-rc1 review patch.  If anyone has any objections, please let me know.
>  > 
>  > --- a/fs/ext4/xattr.c
>  > +++ b/fs/ext4/xattr.c
>  > @@ -1269,6 +1269,8 @@ retry:
>  >s_min_extra_isize) {
>  >tried_min_extra_isize++;
>  >new_extra_isize = s_min_extra_isize;
>  > +  kfree(is); is = NULL;
>  > +  kfree(bs); bs = NULL;
>  >goto retry;
>  >}
>  >error = -1;
> 
> There was a follow-on patch that frees the bh too.

I've only worked through cc'd changes up to 3.12 and that one is later,
so unless you think that's urgent I'll leave it to the next update.

Ben.

-- 
Ben Hutchings
Usenet is essentially a HUGE group of people passing notes in class.
  - Rachel Kadel, `A Quick Guide to Newsgroup Etiquette'


signature.asc
Description: This is a digitally signed message part

Re: [PATCH v2 10/10] intel-gtt: Read 64bit for gmar_bus_addr

[Bjorn Helgaas]

On Mon, Nov 25, 2013 at 6:28 PM, Yinghai Lu  wrote:
> That bar could be 64bit pref mem and above 4G.
>
> -v2: refresh to 3.13-rc1
>
> Signed-off-by: Yinghai Lu 
> Cc: David Airlie 
> Reviewed-by: Daniel Vetter 

This looks OK to me.  Does it depend on any previous patches in this
series?  If not, I think Dave should pick it up.

Bjorn

> ---
>  drivers/char/agp/intel-gtt.c | 14 ++
>  1 file changed, 10 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/char/agp/intel-gtt.c b/drivers/char/agp/intel-gtt.c
> index b8e2014..b929e9d 100644
> --- a/drivers/char/agp/intel-gtt.c
> +++ b/drivers/char/agp/intel-gtt.c
> @@ -609,8 +609,10 @@ static bool intel_gtt_can_wc(void)
>  static int intel_gtt_init(void)
>  {
> u32 gma_addr;
> +   u32 addr_hi = 0;
> u32 gtt_map_size;
> int ret;
> +   int pos;
>
> ret = intel_private.driver->setup();
> if (ret != 0)
> @@ -660,13 +662,17 @@ static int intel_gtt_init(void)
> }
>
> if (INTEL_GTT_GEN <= 2)
> -   pci_read_config_dword(intel_private.pcidev, I810_GMADDR,
> - _addr);
> +   pos = I810_GMADDR;
> else
> -   pci_read_config_dword(intel_private.pcidev, I915_GMADDR,
> - _addr);
> +   pos = I915_GMADDR;
> +
> +   pci_read_config_dword(intel_private.pcidev, pos, _addr);
> +
> +   if (gma_addr & PCI_BASE_ADDRESS_MEM_TYPE_64)
> +   pci_read_config_dword(intel_private.pcidev, pos + 4, 
> _hi);
>
> intel_private.gma_bus_addr = (gma_addr & PCI_BASE_ADDRESS_MEM_MASK);
> +   intel_private.gma_bus_addr |= (u64)addr_hi << 32;
>
> return 0;
>  }
> --
> 1.8.1.4
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

linux-next: Tree for Nov 26

[Stephen Rothwell]

Hi all,

Changes since 20131125:

New trees: arm-v7-cache-opt, chrome-platform

My fixes tree contains:

Revert "powerpc: Add CONFIG_CPU_LITTLE_ENDIAN kernel config option."

The block tree gained conflicts against the f2fs tree and a build failure
for which I applied a merge fix patch.

Non-merge commits (relative to Linus' tree): 1219
 1356 files changed, 61339 insertions(+), 24910 deletions(-)



I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ).  If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one.  You should use "git fetch" as mentioned in the FAQ on the wiki
(see below).

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log files
in the Next directory.  Between each merge, the tree was built with
a ppc64_defconfig for powerpc and an allmodconfig for x86_64 and a
multi_v7_defconfig for arm. After the final fixups (if any), it is also
built with powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig and
allyesconfig (minus CONFIG_PROFILE_ALL_BRANCHES - this fails its final
link) and i386, sparc, sparc64 and arm defconfig. These builds also have
CONFIG_ENABLE_WARN_DEPRECATED, CONFIG_ENABLE_MUST_CHECK and
CONFIG_DEBUG_INFO disabled when necessary.

Below is a summary of the state of the merge.

I am currently merging 210 trees (counting Linus' and 29 trees of patches
pending for Linus' tree).

Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .

Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.

Thanks to Randy Dunlap for doing many randconfig builds.  And to Paul
Gortmaker for triage and bug fixes.

There is a wiki covering stuff to do with linux-next at
http://linux.f-seidel.de/linux-next/pmwiki/ .  Thanks to Frank Seidel.

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au

$ git checkout master
$ git reset --hard stable
Merging origin/master (8e45099e029b Merge tag 'regulator-v3.13-rc1' of 
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator)
Merging fixes/master (f5331539eb90 Revert "powerpc: Add 
CONFIG_CPU_LITTLE_ENDIAN kernel config option.")
Merging kbuild-current/rc-fixes (19514fc665ff arm, kbuild: make "make install" 
not depend on vmlinux)
Merging arc-current/for-curr (97bc386fc12d ARC: Add guard macro to 
uapi/asm/unistd.h)
Merging arm-current/fixes (0c403462d682 ARM: 7894/1: kconfig: select 
GENERIC_CLOCKEVENTS if HAVE_ARM_ARCH_TIMER)
Merging m68k-current/for-linus (77a42796786c m68k: Remove deprecated 
IRQF_DISABLED)
Merging metag-fixes/fixes (3b2f64d00c46 Linux 3.11-rc2)
Merging powerpc-merge/merge (c13f20ac4832 powerpc/signals: Mark VSX not saved 
with small contexts)
Merging sparc/master (b4789b8e6be3 aacraid: prevent invalid pointer dereference)
Merging net/master (2c7a9dc16416 be2net: Avoid programming permenant MAC by 
BE3-R VFs)
Merging ipsec/master (be408cd3e1fe Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net)
Merging sound-current/for-linus (5db4d34b54c7 ALSA: hda - Set 
current_headset_type to ALC_HEADSET_TYPE_ENUM (janitorial))
Merging pci-current/for-linus (4bff6749905d PCI: Move device_del() from 
pci_stop_dev() to pci_destroy_dev())
Merging wireless/master (d5aedd7e1b2f Merge branch 'for-john' of 
git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211)
Merging driver-core.current/driver-core-linus (027a485d12e0 sysfs: use a 
separate locking class for open files depending on mmap)
Merging tty.current/tty-linus (aebf045382ed n_tty: Protect minimum_to_wake 
reset for concurrent readers)
Merging usb.current/usb-linus (043e3f834530 USB: serial: fix write 
memory-allocation flag)
Merging staging.current/staging-linus (67296874eb1c staging: zsmalloc: Ensure 
handle is never 0 on success)
Merging char-misc.current/char-misc-linus (6ce4eac1f600 Linux 3.13-rc1)
Merging input-current/for-linus (5cf0eb9875cb Merge branch 'next' into 
for-linus)
Merging md-current/for-linus (d47648fcf061 raid5: avoid finding "discard" 
stripe)
Merging crypto-current/master (f262f0f5cad0 crypto: s390 - Fix aes-cbc IV 
corruption)
Merging ide/master (c2f7d1e103ef ide: pmac: remove unnecessary 
pci_set_drvdata())
Merging dwmw2/master (5950f0803ca9 pcmcia: remove RPX board stuff)
Merging sh-current/sh-fixes-for-linus (44033109e99c SH: Convert out[bwl] macros 
to inline functions)
Merging devicetree-current/devicetree/merge (1931ee143b0a Revert "drivers: of: 
add initialization code for dma reserved memor

[PATCH V3] n_gsm: race between ld close and gsmtty open

[Chao Bi]

ttyA has ld associated to n_gsm, when ttyA is closing, it triggers
to release gsmttyB's ld data dlci[B], then race would happen if gsmttyB
is opening in parallel.

(Note: This patch set differs from previous set in that it uses mutex
instead of spin lock to avoid race, so that it avoids sleeping in automic
context)

Here are race cases we found recently in test:

CASE #1

releasing dlci[B] race with gsmtty_install(gsmttyB), then panic
in gsmtty_open(gsmttyB), as below:

 tty_release(ttyA)  tty_open(gsmttyB)
 |   |
   -   gsmtty_install(gsmttyB)
 |   |
   -gsm_dlci_alloc(gsmttyB) => alloc dlci[B]
 tty_ldisc_release(ttyA)   -
 |   |
 gsm_dlci_release(dlci[B]) -
 |   |
 gsm_dlci_free(dlci[B])-
 |   |
   -   gsmtty_open(gsmttyB)

 gsmtty_open()
 {
 struct gsm_dlci *dlci = tty->driver_data; => here it uses dlci[B]
 ...
 }

 In gsmtty_open(gsmttyA), it uses dlci[B] which was release, so hit a panic.
=

CASE #2
=
releasing dlci[0] race with gsmtty_install(gsmttyB), then panic
in gsmtty_open(), as below:

 tty_release(ttyA)  tty_open(gsmttyB)
 |   |
   -   gsmtty_install(gsmttyB)
 |   |
   -gsm_dlci_alloc(gsmttyB) => alloc dlci[B]
 |   |
   - gsmtty_open(gsmttyB) fail
 |   |
   -   tty_release(gsmttyB)
 |   |
   -   gsmtty_close(gsmttyB)
 |   |
   -gsmtty_detach_dlci(dlci[B])
 |   |
   - dlci_put(dlci[B])
 |   |
 tty_ldisc_release(ttyA)   -
 |   |
 gsm_dlci_release(dlci[0]) -
 |   |
 gsm_dlci_free(dlci[0])-
 |   |
   - dlci_put(dlci[0])

 In gsmtty_detach_dlci(dlci[B]), it tries to use dlci[0] which was released,
 then hit panic.
=

IMHO, n_gsm tty operations would refer released ldisc,  as long as
gsm_dlci_release() has chance to release ldisc data when some gsmtty operations
are ongoing..

This patch is try to avoid it by:

1) in n_gsm driver, use a global gsm mutex lock to avoid gsm_dlci_release() run 
in
parallel with gsmtty_install();

2) Increase dlci's ref count in gsmtty_install() instead of in gsmtty_open(), 
the
purpose is to prevent gsm_dlci_release() releasing dlci after gsmtty_install()
allocats dlci but before gsmtty_open increases dlci's ref count;

3) Decrease dlci's ref count in gsmtty_remove(), a tty framework API, this is 
the
opposite process of step 2).

Signed-off-by: Chao Bi 
---
 drivers/tty/n_gsm.c |   39 +--
 1 file changed, 29 insertions(+), 10 deletions(-)

diff --git a/drivers/tty/n_gsm.c b/drivers/tty/n_gsm.c
index c0f76da..d514396 100644
--- a/drivers/tty/n_gsm.c
+++ b/drivers/tty/n_gsm.c
@@ -194,6 +194,7 @@ struct gsm_control {
 struct gsm_mux {
struct tty_struct *tty; /* The tty our ldisc is bound to */
spinlock_t lock;
+   struct mutex mutex;
unsigned int num;
struct kref ref;
 
@@ -2054,9 +2055,11 @@ void gsm_cleanup_mux(struct gsm_mux *gsm)
dlci->state == DLCI_CLOSED);
}
/* Free up any link layer users */
+   mutex_lock(>mutex);
for (i = 0; i < NUM_DLCI; i++)
if (gsm->dlci[i])
gsm_dlci_release(gsm->dlci[i]);
+   mutex_unlock(>mutex);
/* Now wipe the queues */
list_for_each_entry_safe(txq, ntxq, >tx_list, list)
kfree(txq);
@@ -2170,6 +2173,7 @@ struct gsm_mux *gsm_alloc_mux(void)
return NULL;
}
spin_lock_init(>lock);
+   mutex_init(>mutex);
kref_init(>ref);
INIT_LIST_HEAD(>tx_list);
 
@@ -2909,23 +2913,33 @@ static int gsmtty_install(struct tty_driver *driver, 
struct tty_struct *tty)
This is ok from a locking
perspective as we don't have to worry about this
if DLCI0 is lost */
-   if (gsm->dlci[0] && 

Re: [PATCH v2 04/10] PCI: Destroy pci dev only once

[Bjorn Helgaas]

On Mon, Nov 25, 2013 at 6:28 PM, Yinghai Lu  wrote:
> Mutliple removing via /sys will call pci_destroy_dev two times.
>
> | When concurent removing pci devices which are in the same pci subtree
> | via sysfs, such as:
> | echo -n 1 > /sys/bus/pci/devices/\:10\:00.0/remove ; echo -n 1 >
> | /sys/bus/pci/devices/\:1a\:01.0/remove
> | (1a:01.0 device is downstream from the 10:00.0 bridge)
> |
> | the following warning will show:
> | [ 1799.280918] [ cut here ]
> | [ 1799.336199] WARNING: CPU: 7 PID: 126 at lib/list_debug.c:53 
> __list_del_entry+0x63/0xd0()
> | [ 1799.433093] list_del corruption, 8807b4a7c000->next is LIST_POISON1 
> (dead00100100)
> | [ 1800.276623] CPU: 7 PID: 126 Comm: kworker/u512:1 Tainted: GW
> 3.12.0-rc5+ #196
> | [ 1800.508918] Workqueue: sysfsd sysfs_schedule_callback_work
> | [ 1800.574703]  0009 8807adbadbd8 8168b26c 
> 8807c27d08a8
> | [ 1800.663860]  8807adbadc28 8807adbadc18 810711dc 
> 8807adbadc68
> | [ 1800.753130]  8807b4a7c000 8807b4a7c000 8807ad089c00 
> 
> | [ 1800.842282] Call Trace:
> | [ 1800.871651]  [] dump_stack+0x55/0x76
> | [ 1800.933301]  [] warn_slowpath_common+0x8c/0xc0
> | [ 1801.005283]  [] warn_slowpath_fmt+0x46/0x50
> | [ 1801.074081]  [] __list_del_entry+0x63/0xd0
> | [ 1801.141839]  [] list_del+0x11/0x40
> | [ 1801.201320]  [] pci_remove_bus_device+0x6a/0xe0
> | [ 1801.274279]  [] 
> pci_stop_and_remove_bus_device+0x1e/0x30
> | [ 1801.356606]  [] remove_callback+0x2b/0x40
> | [ 1801.423412]  [] sysfs_schedule_callback_work+0x18/0x60
> | [ 1801.503744]  [] process_one_work+0x1f5/0x540
> | [ 1801.573640]  [] ? process_one_work+0x193/0x540
> | [ 1801.645616]  [] worker_thread+0x11c/0x370
> | [ 1801.712337]  [] ? rescuer_thread+0x350/0x350
> | [ 1801.782178]  [] kthread+0xed/0x100
> | [ 1801.841661]  [] ? kthread_create_on_node+0x160/0x160
> | [ 1801.919919]  [] ret_from_fork+0x7c/0xb0
> | [ 1801.984608]  [] ? kthread_create_on_node+0x160/0x160
> | [ 1802.062825] ---[ end trace d77f2054de000fb7 ]---
> |
> | This issue is related to the bug 54411:
> | https://bugzilla.kernel.org/show_bug.cgi?id=54411
>
> Add is_removed to record if pci_destroy_dev is called already.
>
> During second calling, still have extra dev ref hold via
> device_schedule_call, so we are safe to check dev->is_removed.
>
> It fixs the problem In Gu's test.
>
> -v2: add partial changelog from Gu Zheng 
>  refresh after patch of moving device_del from Rafael.
>
> Signed-off-by: Yinghai Lu 
> ---
>  drivers/pci/remove.c | 8 +---
>  include/linux/pci.h  | 1 +
>  2 files changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/pci/remove.c b/drivers/pci/remove.c
> index f452148..b090cec 100644
> --- a/drivers/pci/remove.c
> +++ b/drivers/pci/remove.c
> @@ -20,9 +20,11 @@ static void pci_stop_dev(struct pci_dev *dev)
>
>  static void pci_destroy_dev(struct pci_dev *dev)
>  {
> -   device_del(>dev);
> -
> -   put_device(>dev);
> +   if (!dev->is_removed) {
> +   device_del(>dev);
> +   dev->is_removed = 1;

As Rafael pointed out, this looks like a race.  What prevents two
concurrent calls to pci_destroy_dev() from seeing "dev->is_removed ==
0" and both calling device_del() on the same device?

> +   put_device(>dev);
> +   }
>  }
>
>  void pci_remove_bus(struct pci_bus *bus)
> diff --git a/include/linux/pci.h b/include/linux/pci.h
> index 1084a15..ccb316d 100644
> --- a/include/linux/pci.h
> +++ b/include/linux/pci.h
> @@ -321,6 +321,7 @@ struct pci_dev {
> unsigned intmultifunction:1;/* Part of multi-function device */
> /* keep track of device state */
> unsigned intis_added:1;
> +   unsigned intis_removed:1;   /* pci_destroy_dev is called */
> unsigned intis_busmaster:1; /* device is busmaster */
> unsigned intno_msi:1;   /* device may not use msi */
> unsigned intblock_cfg_access:1; /* config space access is 
> blocked */
> --
> 1.8.1.4
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: build warnings after merge of the block tree

[Stephen Rothwell]

Hi all,

On Tue, 26 Nov 2013 13:29:46 +1100 Stephen Rothwell  
wrote:
>
> After merging the block tree, today's linux-next build (arm
> multi_v7_defconfig) produced these warnings:
> 
> block/blk-merge.c: In function 'blk_rq_map_sg':
> block/blk-merge.c:133:8: warning: 'bvprv.bv_len' may be used uninitialized in 
> this function [-Wuninitialized]
> block/blk-merge.c:171:23: note: 'bvprv.bv_len' was declared here
> block/blk-merge.c:133:8: warning: 'bvprv.bv_page' may be used uninitialized 
> in this function [-Wuninitialized]
> block/blk-merge.c:171:23: note: 'bvprv.bv_page' was declared here
> block/blk-merge.c:133:8: warning: 'bvprv.bv_offset' may be used uninitialized 
> in this function [-Wuninitialized]
> block/blk-merge.c:171:23: note: 'bvprv.bv_offset' was declared here
> block/blk-merge.c: In function 'blk_bio_map_sg':
> block/blk-merge.c:133:8: warning: 'bvprv.bv_len' may be used uninitialized in 
> this function [-Wuninitialized]
> block/blk-merge.c:233:23: note: 'bvprv.bv_len' was declared here
> block/blk-merge.c:133:8: warning: 'bvprv.bv_offset' may be used uninitialized 
> in this function [-Wuninitialized]
> block/blk-merge.c:233:23: note: 'bvprv.bv_offset' was declared here
> block/blk-merge.c:133:8: warning: 'bvprv.bv_page' may be used uninitialized 
> in this function [-Wuninitialized]
> block/blk-merge.c:233:23: note: 'bvprv.bv_page' was declared here
> block/blk-merge.c: In function 'attempt_merge':
> block/blk-merge.c:108:7: warning: 'end_bv.bv_offset' may be used 
> uninitialized in this function [-Wuninitialized]
> block/blk-merge.c:89:17: note: 'end_bv.bv_offset' was declared here
> block/blk-merge.c:108:7: warning: 'end_bv.bv_page' may be used uninitialized 
> in this function [-Wuninitialized]
> block/blk-merge.c:89:17: note: 'end_bv.bv_page' was declared here
> block/blk-merge.c:108:7: warning: 'end_bv.bv_len' may be used uninitialized 
> in this function [-Wuninitialized]
> block/blk-merge.c:89:17: note: 'end_bv.bv_len' was declared here
> 
> arm has its own definition of BIOVEC_PHYS_MERGEABLE() if that is relevant.

For an easier test case, the i386 defcongig does this as well.

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


pgpfxLhqbNt7H.pgp
Description: PGP signature

Re: [PATCH] PCI: add a quirk for keeping Bus Master bit on shutdown

[Bjorn Helgaas]

[+cc Lan, Khalid, Konstantin, Alan, Takao, Jility, Florian, linux-kernel]

On Tue, Nov 12, 2013 at 07:40:03PM +, Chang Liu wrote:
> This fixes https://bugzilla.kernel.org/show_bug.cgi?id=63861
>
> Commit b566a22c2 and 7897e60227 made pci_device_shutdown()
> unconditionally clear Bus Master bit for every pci devices.
> While this works for most hardware, certain devices are not
> compatible with this. Intel Lynx Point-LP SATA Controller,
> for example, will hang the system if its Bus Master bit is
> cleared during device shutdown. This patch adds a pci quirk
> so that device drivers can instruct pci_device_shutdown()
> to keep Bus Master from being cleared, and then implements
> this mechanism for the Intel Lynx Point-LP AHCI driver.
>
> Signed-off-by: Chang Liu 

I'm not 100% comfortable with disabling bus mastering in general;
see [1] for more details.

But given that we have been doing it for quite a while (b566a22c2 appeared
in v3.5 on Jul 21, 2012), and Lynx Point should be in lots of machines, I'm
surprised that we don't see more reports of this problem if it really
affects all Lynx Point parts.

Jility reported the same problem [2], and I did find one other similar
report [3] from Florian.  All three reports (Chang, Jility, Florian) are on
the same exact machine (Acer V5-573G), which seems sort of suspicious.

Lan, do you have access to any Lynx Point boxes?  Can you test and see
whether they hang on power-off also?  I suspect this might be something
specific to the Acer box, not a generic Lynx Point issue.

Bjorn

[1] http://lkml.kernel.org/r/20120427190033.ga17...@ldl.usa.hp.com
[2] https://bugzilla.kernel.org/show_bug.cgi?id=63861#c21
[3] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1249329

> ---
> As per Takao's suggestion, add a new member into struct pci_dev
> and add a quirk in the ahci driver. I tested this on my
> machine (Acer V5-573G) and it works fine.
>
>  drivers/ata/ahci.c   |  8 
>  drivers/pci/pci-driver.c | 11 ---
>  include/linux/pci.h  |  1 +
>  3 files changed, 17 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c
> index 8e28f92..de6efcb 100644
> --- a/drivers/ata/ahci.c
> +++ b/drivers/ata/ahci.c
> @@ -1385,6 +1385,14 @@ static int ahci_init_one(struct pci_dev *pdev, const 
> struct pci_device_id *ent)
>
>   pci_set_master(pdev);
>
> + /* We normally clear Bus Master on pci device shutdown. However,
> + * doing so for Intel Lynx Point-LP SATA Controller [AHCI mode]
> + * hangs the system. Therefore keep it.
> + * See bug report: https://bugzilla.kernel.org/show_bug.cgi?id=63861
> + */
> + if (pdev->vendor == PCI_VENDOR_ID_INTEL && pdev->device == 0x9c03)
> + pdev->keep_busmaster_on_shutdown = 1;
> +
>   if (hpriv->flags & AHCI_HFLAG_MULTI_MSI)
>   return ahci_host_activate(host, pdev->irq, n_msis);
>
> diff --git a/drivers/pci/pci-driver.c b/drivers/pci/pci-driver.c
> index 38f3c01..ff15b0c 100644
> --- a/drivers/pci/pci-driver.c
> +++ b/drivers/pci/pci-driver.c
> @@ -392,10 +392,15 @@ static void pci_device_shutdown(struct device *dev)
>   pci_msix_shutdown(pci_dev);
>
>   /*
> - * Turn off Bus Master bit on the device to tell it to not
> - * continue to do DMA. Don't touch devices in D3cold or unknown states.
> + * If the hardware is okay with it, turn off Bus Master bit
> + * on the device to tell it not to continue doing DMA.
> + * Don't touch devices in D3cold or unknown states.
> + * On certain hardware clearing Bus Master bit on shutdown
> + * may hang the entire system. In these cases the driver of
> + * these devices should set keep_busmaster_on_shutdown to 1.
>   */
> - if (pci_dev->current_state <= PCI_D3hot)
> + if (!pci_dev->keep_busmaster_on_shutdown
> +&& pci_dev->current_state <= PCI_D3hot)
>   pci_clear_master(pci_dev);
>  }
>
> diff --git a/include/linux/pci.h b/include/linux/pci.h
> index da172f9..63db735 100644
> --- a/include/linux/pci.h
> +++ b/include/linux/pci.h
> @@ -322,6 +322,7 @@ struct pci_dev {
>   /* keep track of device state */
>   unsigned int is_added:1;
>   unsigned int is_busmaster:1; /* device is busmaster */
> + unsigned int keep_busmaster_on_shutdown:1; /* do not clear busmaster on 
> shutdown */
>   unsigned int no_msi:1; /* device may not use msi */
>   unsigned int block_cfg_access:1; /* config space access is blocked */
>   unsigned int broken_parity_status:1; /* Device generates false positive 
> parity */
> --
> 1.8.4.2
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 02/16] staging/lustre/llog: MGC to use OSD API for backup logs

[Greg Kroah-Hartman]

On Tue, Nov 26, 2013 at 11:25:24AM +0800, Peng Tao wrote:
> On Tue, Nov 26, 2013 at 11:14 AM, Greg Kroah-Hartman
>  wrote:
> > On Tue, Nov 26, 2013 at 10:04:56AM +0800, Peng Tao wrote:
> >> From: Mikhail Pershin 
> >>
> >> MGC uses lvfs API to access local llogs blocking removal of old code
> >>
> >> - MGS is converted to use OSD API for local llogs
> >> - llog_is_empty() and llog_backup() are introduced
> >> - initial OSD start initialize run ctxt so llog can use it too
> >> - shrink dcache after initial scrub in osd-ldiskfs to avoid holding
> >>   data of unlinked objects until umount.
> >
> > It is not checkpatch clean :(
> >
> > Come on, it's not hard to do this yourself, why do you make me find
> > these errors for you?  It does nothing but make me not want to look at
> > lustre patches for a long time...
> 
> Strange. I did run checkpatch before sending the patchset out.
> 
> Just tried again. Still pass.
> 
> [X61@linux-lustre]$./scripts/checkpatch.pl
> 0002-staging-lustre-llog-MGC-to-use-OSD-API-for-backup-lo.patch total:
> 0 errors, 0 warnings, 883 lines checked
> 
> 0002-staging-lustre-llog-MGC-to-use-OSD-API-for-backup-lo.patch has no
> obvious style problems and is ready for submission.
> 
> What message did you see?

One about return();

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] I2C: BCM2835: Linking platform nodes to adapter nodes

[Stephen Warren]

On 11/08/2013 09:59 AM, Stephen Warren wrote:
> On 11/08/2013 02:49 AM, Florian Meier wrote:
>> In order to find I2C devices in the device tree, the platform nodes
>> have to be known by the I2C core. Analogous to the i2c-omap driver
>> this requires setting the dev.of_node parameter of the adapter.
> 
> (CCing the I2C maintainers...)
> 
>> diff --git a/drivers/i2c/busses/i2c-bcm2835.c 
>> b/drivers/i2c/busses/i2c-bcm2835.c
> 
>> @@ -299,6 +299,7 @@ static int bcm2835_i2c_probe(struct platform_device 
>> *pdev)
>>  strlcpy(adap->name, "bcm2835 I2C adapter", sizeof(adap->name));
>>  adap->algo = _i2c_algo;
>>  adap->dev.parent = >dev;
>> +adap->dev.of_node = pdev->dev.of_node;
> 
> Ah, that makes sense. Thinking about it now, I'd only ever used i2cget
> etc. to access I2C devices, rather than instantiating drivers from DT.
> 
> That all said, I wonder if the I2C core shouldn't do something like the
> following inside i2c_add_adapter():
> 
> if (!adap->dev.of_node && adap->dev.parent)
>   adap->dev.of_node = adap->dev.parent->of_node;
> 
> That would save every single I2C driver from having to set up this field
> manually.

BTW, this should probably be:
Cc: sta...@vger.kernel.org
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH RFC] gpio: omap: refresh the patch “gpio: omap: be more aggressive with pm_runtime” against v3.12-rc5

[Chao Xu]

Refresh the patch “gpio: omap: be more aggressive with pm_runtime” by
Felipe Balbi against v3.12-rc5. Add version checking so that the
aggressive pm_runtime only applies to omap4 devices. Tested with
pandaboard rev a2 through sysfs.
Signed-off-by: Chao Xu 
---
According to Mr. Felipe Balbi, the original patch was not accepted
because interrupts would be missed when GPIO was used as IRQ source.
But in my tests with pandaboard, interrupts were not missed. This is
because _idle_sysc() sets the idlemode of gpio module to
smart-idle-wakeup, and according to OMAP4430 TRM, under this idlemode,
the gpio can generate an asynchronous wakeup request to the PRCM. And
after GPIO is awake, the wake-up request is reflected into the
interrupt status registers.

A change I made against the original patch is only using the
aggressive runtime pm scheme on OMAP4 by adding a flag in pdata,
because I don’t have HW to test OMAP3 or am33xx devices. According to
the respective TRMs, their GPIO modules also can generate wake-up
request if the idlemode is set to smart-idle or smart-idle-wakeup. So
the patch should work for them, too. But I suspect a potential SW bug
may cause missed interrupts: the am33xx_gpio_sysc.idlemodes is marked
as capable of SIDLE_SMART_WKUP in omap_hwmod_33xx.c. But according to
AM335x TRM, _only_ gpio0 is capable of this mode. This may make GPIO
stuck in force-idle mode and unable to generate wakeup request. And
thus interrupt will be missed. Again, I don’t have the HW to verify
whether this is a bug or not :(

 drivers/gpio/gpio-omap.c|  103 ++-
 include/linux/platform_data/gpio-omap.h |1 +
 2 files changed, 87 insertions(+), 17 deletions(-)

diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index 89675f8..90661f2 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -76,6 +76,7 @@ struct gpio_bank {
  int context_loss_count;
  int power_mode;
  bool workaround_enabled;
+ bool is_aggressive_pm;

  void (*set_dataout)(struct gpio_bank *bank, int gpio, int enable);
  int (*get_context_loss_count)(struct device *dev);
@@ -473,8 +474,15 @@ static void _disable_gpio_module(struct gpio_bank
*bank, unsigned offset)
 static int gpio_is_input(struct gpio_bank *bank, int mask)
 {
  void __iomem *reg = bank->base + bank->regs->direction;
+ u32 val;

- return __raw_readl(reg) & mask;
+ if (bank->is_aggressive_pm)
+ pm_runtime_get_sync(bank->dev);
+ val = __raw_readl(reg) & mask;
+ if (bank->is_aggressive_pm)
+ pm_runtime_put(bank->dev);
+
+ return val;
 }

 static int gpio_irq_type(struct irq_data *d, unsigned type)
@@ -485,7 +493,7 @@ static int gpio_irq_type(struct irq_data *d, unsigned type)
  unsigned long flags;
  unsigned offset;

- if (!BANK_USED(bank))
+ if (!BANK_USED(bank) && !bank->is_aggressive_pm)
  pm_runtime_get_sync(bank->dev);

 #ifdef CONFIG_ARCH_OMAP1
@@ -503,6 +511,8 @@ static int gpio_irq_type(struct irq_data *d, unsigned type)
  (type & (IRQ_TYPE_LEVEL_LOW|IRQ_TYPE_LEVEL_HIGH)))
  return -EINVAL;

+ if (bank->is_aggressive_pm)
+ pm_runtime_get_sync(bank->dev);
  spin_lock_irqsave(>lock, flags);
  offset = GPIO_INDEX(bank, gpio);
  retval = _set_gpio_triggering(bank, offset, type);
@@ -511,11 +521,16 @@ static int gpio_irq_type(struct irq_data *d,
unsigned type)
  _set_gpio_direction(bank, offset, 1);
  } else if (!gpio_is_input(bank, 1 << offset)) {
  spin_unlock_irqrestore(>lock, flags);
+ if (bank->is_aggressive_pm)
+ pm_runtime_put(bank->dev);
+
  return -EINVAL;
  }

  bank->irq_usage |= 1 << GPIO_INDEX(bank, gpio);
  spin_unlock_irqrestore(>lock, flags);
+ if (bank->is_aggressive_pm)
+ pm_runtime_put(bank->dev);

  if (type & (IRQ_TYPE_LEVEL_LOW | IRQ_TYPE_LEVEL_HIGH))
  __irq_set_handler_locked(d->irq, handle_level_irq);
@@ -668,10 +683,11 @@ static int omap_gpio_request(struct gpio_chip
*chip, unsigned offset)
  unsigned long flags;

  /*
- * If this is the first gpio_request for the bank,
- * enable the bank module.
+ * if aggressive runtime pm is supported, enable the bank module
+ * for each gpio_request. Otherwise enable the bank module if this
+ * is the first gpio_request for the bank.
  */
- if (!BANK_USED(bank))
+ if (bank->is_aggressive_pm || !BANK_USED(bank))
  pm_runtime_get_sync(bank->dev);

  spin_lock_irqsave(>lock, flags);
@@ -685,7 +701,8 @@ static int omap_gpio_request(struct gpio_chip
*chip, unsigned offset)
  }
  bank->mod_usage |= 1 << offset;
  spin_unlock_irqrestore(>lock, flags);
-
+ if (bank->is_aggressive_pm)
+ pm_runtime_put(bank->dev);
  return 0;
 }

@@ -694,6 +711,9 @@ static void omap_gpio_free(struct gpio_chip *chip,
unsigned offset)
  struct gpio_bank *bank = container_of(chip, struct gpio_bank, chip);
  unsigned long flags;

+ if (bank->is_aggressive_pm)
+ pm_runtime_get_sync(bank->dev);
+
  spin_lock_irqsave(>lock, flags);
  bank->mod_usage &= ~(1 << offset);
  _disable_gpio_module(bank, offset);
@@ -701,10 +721,11 @@ static void omap_gpio_free(struct gpio_chip
*chip, 

Re: /proc/vmcore mmap() failure issue

[chaow...@redhat.com]

On 11/25/13 at 08:09am, Atsushi Kumagai wrote:
> Hello WANG,
> 
> On 2013/11/21 16:15:22, kexec  wrote:
> > > How about this fail back structure instead of such an extra option ?
> > > 
> > > Thanks
> > > Atsushi Kumagai
> > > 
> > > From: Atsushi Kumagai 
> > > Date: Wed, 20 Nov 2013 14:10:19 +0900
> > > Subject: [PATCH] Fall back to read() when mmap() fails.
> > > 
> > > Signed-off-by: Atsushi Kumagai 
> > > ---
> > >  makedumpfile.c | 10 +-
> > >  1 file changed, 9 insertions(+), 1 deletion(-)
> > > 
> > > diff --git a/makedumpfile.c b/makedumpfile.c
> > > index ca03440..f583602 100644
> > > --- a/makedumpfile.c
> > > +++ b/makedumpfile.c
> > > @@ -324,7 +324,15 @@ read_from_vmcore(off_t offset, void *bufptr, 
> > > unsigned long size)
> > >   if (!read_with_mmap(offset, bufptr, size)) {
> > >   ERRMSG("Can't read the dump memory(%s) with mmap().\n",
> > >  info->name_memory);
> > > - return FALSE;
> > > +
> > > + ERRMSG("This kernel might have some problems about 
> > > mmap().\n");
> > > + ERRMSG("read() will be used instead of mmap() from 
> > > now.\n");
> > > +
> > > + /*
> > > +  * Fall back to read().
> > > +  */
> > > + info->flag_usemmap = FALSE;
> > > + read_from_vmcore(offset, bufptr, size);
> > 
> > Hi, Atsushi
> > 
> > I've got such a workstation too. And I confirm this patch works for me.
> 
> Thanks for your testing !
> 
> > However, I have a question:
> > Why not switch to mmap() back after read()?
> 
> I made this patch as a general safety net, not only for the partial page
> issue.
> When facing unknown issues related mmap(), the kernel may have some bugs
> and mmap() can fail for every pages. In the worst case, most all mmap()
> will fail and try read() with error messages after every fail, but this
> patch will prevent the chattering of the switch and so many error messages.

Thanks for you explanation. I agree with you. Since mmap() is error
prone after first mmap failure, use read() instead as a fail safe makes
much sense to me.

WANG Chao
> 
> 
> Thanks
> Atsushi Kumagai
> 
> > Thanks
> > WANG Chao
> > 
> > >   }
> > >   } else {
> > >   if (lseek(info->fd_memory, offset, SEEK_SET) == failed) {
> > > -- 
> > > 1.8.0.2
> > 
> > ___
> > kexec mailing list
> > ke...@lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/kexec
> > 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 08/16] staging/lustre/mdt: HSM coordinator agent interface

[Greg Kroah-Hartman]

On Tue, Nov 26, 2013 at 10:05:02AM +0800, Peng Tao wrote:
> From: JC Lafoucriere 
> 
> To move data with external storage, HSM coordinator
> uses a Copy Tool running on a client named agent.
> This patch implements the interface for these agents.

Interesting text here...

> Lustre-change: http://review.whamcloud.com/6534
> Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-3342
> Signed-off-by: JC Lafoucriere 
> Reviewed-by: Jinshan Xiong 
> Reviewed-by: Andreas Dilger 
> Reviewed-by: John L. Hammond 
> Reviewed-by: Oleg Drokin 
> Signed-off-by: Peng Tao 
> Signed-off-by: Andreas Dilger 
> ---
>  .../lustre/lustre/include/lustre/lustre_user.h |6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/staging/lustre/lustre/include/lustre/lustre_user.h 
> b/drivers/staging/lustre/lustre/include/lustre/lustre_user.h
> index 9436166..631f026 100644
> --- a/drivers/staging/lustre/lustre/include/lustre/lustre_user.h
> +++ b/drivers/staging/lustre/lustre/include/lustre/lustre_user.h
> @@ -428,8 +428,8 @@ struct obd_uuid {
>   char uuid[UUID_MAX];
>  };
>  
> -static inline int obd_uuid_equals(const struct obd_uuid *u1,
> -   const struct obd_uuid *u2)
> +static inline bool obd_uuid_equals(const struct obd_uuid *u1,
> +const struct obd_uuid *u2)
>  {
>   return strcmp((char *)u1->uuid, (char *)u2->uuid) == 0;
>  }
> @@ -446,7 +446,7 @@ static inline void obd_str2uuid(struct obd_uuid *uuid, 
> const char *tmp)
>  }
>  
>  /* For printf's only, make sure uuid is terminated */
> -static inline char *obd_uuid2str(struct obd_uuid *uuid)
> +static inline char *obd_uuid2str(const struct obd_uuid *uuid)
>  {
>   if (uuid->uuid[sizeof(*uuid) - 1] != '\0') {
>   /* Obviously not safe, but for printfs, no real harm done...

Too bad it doesn't describe the changes made in the code at all.

How can so many people review a patch that is not the same as what it
says it really is?

I'm stopping here in the series, sorry.  Please fix up and resend the
rest when you can.

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCHv7 0/4] twl4030-pwrbutton DT binding

[Dmitry Torokhov]

On Sun, Nov 24, 2013 at 05:33:44PM +0100, Sebastian Reichel wrote:
> Hi,
> 
> On Fri, Nov 08, 2013 at 11:11:23PM +0100, Sebastian Reichel wrote:
> > This is the seventh iteration of DT support for the TWL4030
> > power button.
> 
> Dmitry, can you add this patchset to your queue?
> 
> It got no further comments in two weeks.

Yes, I just applied the series.

Thanks.

-- 
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

GPF in aio_migratepage

[Dave Jones]

Hi Kent,

I hit the GPF below on a tree based on 8e45099e029bb6b369b27d8d4920db8caff5ecce
which has your commit e34ecee2ae791df674dfb466ce40692ca6218e43
("aio: Fix a trinity splat").  Is this another path your patch missed, or
a completely different bug to what you were chasing ?

Dave

general protection fault:  [#1] PREEMPT SMP DEBUG_PAGEALLOC
Modules linked in: snd_seq_dummy bridge stp tun fuse hidp bnep rfcomm ipt_ULOG 
can_bcm scsi_transport_iscsi nfc caif_socket caif af_802154 phonet af_rxrpc 
bluetooth rfkill can_raw can llc2 pppoe pppox ppp_generic slhc irda crc_ccitt 
rds nfnetlink af_key rose x25 atm netrom appletalk ipx p8023 psnap p8022 llc 
ax25 xfs libcrc32c coretemp hwmon x86_pkg_temp_thermal kvm_intel 
snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_intel snd_hda_codec kvm 
snd_hwdep snd_seq snd_seq_device crct10dif_pclmul snd_pcm snd_page_alloc 
snd_timer snd crc32c_intel ghash_clmulni_intel shpchp usb_debug e1000e 
soundcore microcode pcspkr ptp pps_core serio_raw
CPU: 3 PID: 1840 Comm: trinity-child3 Not tainted 3.13.0-rc1+ #9 
task: 88003b3a15d0 ti: 88001f208000 task.ti: 88001f208000
RIP: 0010:[]  [] __lock_acquire+0x1b1/0x19f0
RSP: 0018:88001f209740  EFLAGS: 00010002
RAX: 6b6b6b6b6b6b6b6b RBX: 0002 RCX: 
RDX:  RSI:  RDI: 88001fbf3760
RBP: 88001f2097e8 R08: 0002 R09: 0001
R10:  R11:  R12: 88003b3a15d0
R13: 6b6b6b6b6b6b6b6b R14: 88001fbf3760 R15: 
FS:  7faab2396740() GS:880244e0() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 7f4e589ba36c CR3: 1f2fa000 CR4: 001407e0
DR0:  DR1:  DR2: 
DR3:  DR6: fffe0ff0 DR7: 0400
Stack:
 0006 810a970f 0006 050b04f1418f
 88001f209778 8100b164 824cb6a0 810a970f
  88003b3a1cd8 0007 0006
Call Trace:
 [] ? trace_hardirqs_off_caller+0x1f/0xc0
 [] ? native_sched_clock+0x24/0x80
 [] ? trace_hardirqs_off_caller+0x1f/0xc0
 [] ? mark_held_locks+0xbb/0x140
 [] lock_acquire+0x93/0x1c0
 [] ? aio_migratepage+0xa6/0x150
 [] _raw_spin_lock_irqsave+0x4b/0x90
 [] ? aio_migratepage+0xa6/0x150
 [] aio_migratepage+0xa6/0x150
 [] move_to_new_page+0x79/0x240
 [] migrate_pages+0x7a5/0x850
 [] ? isolate_freepages_block+0x440/0x440
 [] compact_zone+0x2ba/0x510
 [] compact_zone_order+0x94/0xe0
 [] try_to_compact_pages+0xe1/0x110
 [] __alloc_pages_direct_compact+0xac/0x1d0
 [] __alloc_pages_nodemask+0x996/0xb50
 [] alloc_pages_vma+0xf1/0x1b0
 [] ? do_huge_pmd_anonymous_page+0xfd/0x3a0
 [] do_huge_pmd_anonymous_page+0xfd/0x3a0
 [] ? lock_release_holdtime.part.29+0xe6/0x160
 [] handle_mm_fault+0x479/0xbb0
 [] ? __lock_is_held+0x57/0x80
 [] __get_user_pages+0x1ae/0x5f0
 [] __mlock_vma_pages_range+0x8c/0xa0
 [] __mm_populate+0xc0/0x150
 [] vm_mmap_pgoff+0xb6/0xc0
 [] SyS_mmap_pgoff+0x116/0x270
 [] ia32_do_call+0x13/0x13
Code: c2 b6 75 a2 81 31 c0 be fb 0b 00 00 48 c7 c7 00 b6 a2 81 e8 b2 6d fa ff 
eb a8 44 89 fa 4d 8b 6c d6 08 4d 85 ed 0f 84 cb fe ff ff  41 ff 85 98 01 00 
00 8b 05 b9 28 9b 01 45 8b bc 24 00 07 00 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 02/16] staging/lustre/llog: MGC to use OSD API for backup logs

[Peng Tao]

On Tue, Nov 26, 2013 at 11:14 AM, Greg Kroah-Hartman
 wrote:
> On Tue, Nov 26, 2013 at 10:04:56AM +0800, Peng Tao wrote:
>> From: Mikhail Pershin 
>>
>> MGC uses lvfs API to access local llogs blocking removal of old code
>>
>> - MGS is converted to use OSD API for local llogs
>> - llog_is_empty() and llog_backup() are introduced
>> - initial OSD start initialize run ctxt so llog can use it too
>> - shrink dcache after initial scrub in osd-ldiskfs to avoid holding
>>   data of unlinked objects until umount.
>
> It is not checkpatch clean :(
>
> Come on, it's not hard to do this yourself, why do you make me find
> these errors for you?  It does nothing but make me not want to look at
> lustre patches for a long time...

Strange. I did run checkpatch before sending the patchset out.

Just tried again. Still pass.

[X61@linux-lustre]$./scripts/checkpatch.pl
0002-staging-lustre-llog-MGC-to-use-OSD-API-for-backup-lo.patch total:
0 errors, 0 warnings, 883 lines checked

0002-staging-lustre-llog-MGC-to-use-OSD-API-for-backup-lo.patch has no
obvious style problems and is ready for submission.

What message did you see?

Thanks,
Tao
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] n_gsm: race between ld close and gsmtty open

[channing]

On Mon, 2013-11-25 at 19:16 -0800, Greg KH wrote:
> > > 
> > > What is different from the previous version?  That information needs to
> > > be somewhere, otherwise I'm just going to guess and say this is the same
> > > as your last one, which was incorrect.
> > The difference with previous one is to use a mutex instead of spin lock
> > to avoid race, purpose is to avoid sleep in atomic context. I've also
> > updated commit a little as above.
> 
> Then be explicit as to what has changed somewhere.  We deal with
> thousands of patches a week, we can not know that you changed one
> sentance in a patch description of a few hundred lines long to know you
> made a change to the patch itself as well...
OK, in next patch set, I'll highlight difference with previous patch
set.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 07/15] KVM: MMU: introduce nulls desc

[Xiao Guangrong]

On 11/26/2013 02:12 AM, Marcelo Tosatti wrote:
> On Mon, Nov 25, 2013 at 02:29:03PM +0800, Xiao Guangrong wrote:
 Also, there is no guarantee of termination (as long as sptes are
 deleted with the correct timing). BTW, can't see any guarantee of
 termination for rculist nulls either (a writer can race with a lockless
 reader indefinately, restarting the lockless walk every time).
>>>
>>> Hmm, that can be avoided by checking dirty-bitmap before rewalk,
>>> that means, if the dirty-bitmap has been set during lockless 
>>> write-protection,
>>> it�s unnecessary to write-protect its sptes. Your idea?
>> This idea is based on the fact that the number of rmap is limited by
>> RMAP_RECYCLE_THRESHOLD. So, in the case of adding new spte into rmap,
>> we can break the rewalk at once, in the case of deleting, we can only
>> rewalk RMAP_RECYCLE_THRESHOLD times.
> 
> Please explain in more detail.

Okay.

My proposal is like this:

pte_list_walk_lockless()
{
restart:

+   if (__test_bit(slot->arch.dirty_bitmap, gfn-index))
+   return;

code-doing-lockless-walking;
..
}

Before do lockless-walking, we check the dirty-bitmap first, if
it is set we can simply skip write-protection for the gfn, that
is the case that new spte is being added into rmap when we lockless
access the rmap.

For the case of deleting spte from rmap, the number of entry is limited
by RMAP_RECYCLE_THRESHOLD, that is not endlessly.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] n_gsm: race between ld close and gsmtty open

[Greg KH]

On Tue, Nov 26, 2013 at 11:35:14AM +0800, channing wrote:
> On Mon, 2013-11-25 at 18:54 -0800, Greg KH wrote:
> > On Tue, Nov 26, 2013 at 11:14:05AM +0800, channing wrote:
> 
> > > This patch is try to avoid it by:
> > > 
> > > 1) in n_gsm driver, use a global gsm mutex lock to avoid 
> > > gsm_dlci_release() run in
> > > parallel with gsmtty_install();
> The commit is updated here than formal patch set: we use mutex lock in
> patch V2, while use spin lock in patch V1.
> 
> > > 
> > > 2) Increase dlci's ref count in gsmtty_install() instead of in 
> > > gsmtty_open(), the
> > > purpose is to prevent gsm_dlci_release() releasing dlci after 
> > > gsmtty_install()
> > > allocats dlci but before gsmtty_open increases dlci's ref count;
> > > 
> > > 3) Decrease dlci's ref count in gsmtty_remove(), a tty framework API, 
> > > this is the
> > > opposite process of step 2).
> > > 
> > > Signed-off-by: Chao Bi 
> > > Signed-off-by: Greg Kroah-Hartman 
> > 
> > I have not signed off on this additional patch.
> > 
> > What is different from the previous version?  That information needs to
> > be somewhere, otherwise I'm just going to guess and say this is the same
> > as your last one, which was incorrect.
> The difference with previous one is to use a mutex instead of spin lock
> to avoid race, purpose is to avoid sleep in atomic context. I've also
> updated commit a little as above.

Then be explicit as to what has changed somewhere.  We deal with
thousands of patches a week, we can not know that you changed one
sentance in a patch description of a few hundred lines long to know you
made a change to the patch itself as well...

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 02/16] staging/lustre/llog: MGC to use OSD API for backup logs

[Greg Kroah-Hartman]

On Tue, Nov 26, 2013 at 10:04:56AM +0800, Peng Tao wrote:
> From: Mikhail Pershin 
> 
> MGC uses lvfs API to access local llogs blocking removal of old code
> 
> - MGS is converted to use OSD API for local llogs
> - llog_is_empty() and llog_backup() are introduced
> - initial OSD start initialize run ctxt so llog can use it too
> - shrink dcache after initial scrub in osd-ldiskfs to avoid holding
>   data of unlinked objects until umount.

It is not checkpatch clean :(

Come on, it's not hard to do this yourself, why do you make me find
these errors for you?  It does nothing but make me not want to look at
lustre patches for a long time...
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 07/15] KVM: MMU: introduce nulls desc

[Xiao Guangrong]

On 11/25/2013 10:23 PM, Marcelo Tosatti wrote:
> On Mon, Nov 25, 2013 at 02:48:37PM +0200, Avi Kivity wrote:
>> On Mon, Nov 25, 2013 at 8:11 AM, Xiao Guangrong
>>  wrote:
>>>
>>> On Nov 23, 2013, at 3:14 AM, Marcelo Tosatti  wrote:
>>
>> 
>>
>> I'm not really following, but note that parent_pte predates EPT (and
>> the use of rcu in kvm), so all the complexity that is the result of
>> trying to pack as many list entries into a cache line can be dropped.
>> Most setups now would have exactly one list entry, which is handled
>> specially antyway.
>>
>> Alternatively, the trick of storing multiple entries in one list entry
>> can be moved to generic code, it may be useful to others.
> 
> Yes, can the lockless list walking code be transformed into generic
> single-linked list walking? So the correctness can be verified
> independently, and KVM becomes a simple user of that interface.

I'am afraid the signle-entry list is not so good as we expected. In my
experience, there're too many entries on rmap, more than 300 sometimes.
(consider a case that a lib shared by all processes).

> 
> The simpler version is to maintain lockless walk on depth-1 rmap entries
> (and grab the lock once depth-2 entry is found).

I still think rmap-lockless is more graceful: soft mmu can get benefit
from it also it is promising to be used in some mmu-notify functions. :)


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] n_gsm: race between ld close and gsmtty open

[channing]

On Mon, 2013-11-25 at 18:54 -0800, Greg KH wrote:
> On Tue, Nov 26, 2013 at 11:14:05AM +0800, channing wrote:

> > This patch is try to avoid it by:
> > 
> > 1) in n_gsm driver, use a global gsm mutex lock to avoid gsm_dlci_release() 
> > run in
> > parallel with gsmtty_install();
The commit is updated here than formal patch set: we use mutex lock in
patch V2, while use spin lock in patch V1.

> > 
> > 2) Increase dlci's ref count in gsmtty_install() instead of in 
> > gsmtty_open(), the
> > purpose is to prevent gsm_dlci_release() releasing dlci after 
> > gsmtty_install()
> > allocats dlci but before gsmtty_open increases dlci's ref count;
> > 
> > 3) Decrease dlci's ref count in gsmtty_remove(), a tty framework API, this 
> > is the
> > opposite process of step 2).
> > 
> > Signed-off-by: Chao Bi 
> > Signed-off-by: Greg Kroah-Hartman 
> 
> I have not signed off on this additional patch.
> 
> What is different from the previous version?  That information needs to
> be somewhere, otherwise I'm just going to guess and say this is the same
> as your last one, which was incorrect.
The difference with previous one is to use a mutex instead of spin lock
to avoid race, purpose is to avoid sleep in atomic context. I've also
updated commit a little as above.

> 
> Also, please fix your "From:" line in your email client to match your
> Signed-off-by: line, or else add the proper "From:" line to your patch,
> as the Documentation/SubmittingPatches file says.
> 
> Care to try again?
Yes, I'll correct it. thanks.
> 
> greg k-h


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/