Re: [v3.20] Regression: V3.20 doesn'nt wake up from suspend

[Jörg Otte]

2015-02-13 15:40 GMT+01:00 Rafael J. Wysocki :
> On Friday, February 13, 2015 09:49:20 AM Jörg Otte wrote:
>> In suspend state the power-led remains on (should be blinking).
>> So may be the kernel does not reach suspend state correctly.
>> Once suspended, pressing the suspend key to wake up does not have
>> any visible effect.
>>
>> There is nothing special in the logs.
>>
>> I tried to bisect, but I ran into an unbootable kernel, so all I
>> can say is:
>> Last good kernel:  3.19.0-00463-g3e8c04e
>> First bad kernel:  3.19.0-02595-gc5ce28d
>>
>> Suspend has always been working, so this a regression.
>>
>> It is a FUJITSU LIFEBOOK AH532/FJNBB1C, BIOS Version 1.09 05/22/2012
>
> I'll be sending a pull request with one revert related to broken suspend
> later today, so hopefully this will help you too.

Yes it fixed it.

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

Re: [PATCH 0/4] mm: cma: add some debug information for CMA

[Gioh Kim]

2015-02-13 오후 12:03에 Joonsoo Kim 이(가) 쓴 글:

On Fri, Feb 13, 2015 at 01:15:40AM +0300, Stefan Strogin wrote:

Hi all.

Sorry for the long delay. Here is the second attempt to add some facility
for debugging CMA (the first one was "mm: cma: add /proc/cmainfo" [1]).

This patch set is based on v3.19 and Sasha Levin's patch set
"mm: cma: debugfs access to CMA" [2].
It is also available on git:
git://github.com/stefanstrogin/cmainfo -b cmainfo-v2

We want an interface to see a list of currently allocated CMA buffers and
some useful information about them (like /proc/vmallocinfo but for physically
contiguous buffers allocated with CMA).

Here is an example use case when we need it. We want a big (megabytes)
CMA buffer to be allocated in runtime in default CMA region. If someone
already uses CMA then the big allocation can fail. If it happens then with
such an interface we could find who used CMA at the moment of failure, who
caused fragmentation (possibly ftrace also would be helpful here) and so on.


Hello,

So, I'm not sure that information about allocated CMA buffer is really
needed to solve your problem. You just want to know who uses default CMA
region and you can know it by adding tracepoint in your 4/4 patch. We
really need this custom allocation tracer? What can we do more with
this custom tracer to solve your problem? Could you more specific
about your problem and how to solve it by using this custom tracer?



These patches add some files to debugfs when CONFIG_CMA_DEBUGFS is enabled.


If this tracer is justifiable, I think that making it conditional is
better than just enabling always on CONFIG_CMA_DEBUGFS. Some users
don't want to this feature although they enable CONFIG_CMA_DEBUGFS.

Thanks.



Hello,

Thanks for your work. It must be helpful to me.

What about add another option to activate stack-trace?
In my platform I know all devices using cma area, so I usually don't need 
stack-trace.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/4] mm: cma: add functions to get region pages counters

[Gioh Kim]

2015-02-13 오전 7:15에 Stefan Strogin 이(가) 쓴 글:
> From: Dmitry Safonov 
> 
> Here are two functions that provide interface to compute/get used size
> and size of biggest free chunk in cma region.

I usually just try to allocate memory, not check free size before try,
becuase free size can be changed after I check it.

Could you tell me why biggest free chunk size is necessary?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.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] drm/radeon: Fix regression with suspend/resume

[Deucher, Alexander]

> -Original Message-
> From: Ross Zwisler [mailto:ross.zwis...@linux.intel.com]
> Sent: Friday, February 13, 2015 10:55 PM
> To: Michel Dänzer
> Cc: linux-kernel@vger.kernel.org; dri-de...@lists.freedesktop.org; Deucher,
> Alexander; Dave Airlie; Lauri Kasanen; Koenig, Christian
> Subject: Re: [PATCH] drm/radeon: Fix regression with suspend/resume
> 
> On Fri, 2015-02-13 at 11:41 +0900, Michel Dänzer wrote:
> > On 13.02.2015 05:30, Ross Zwisler wrote:
> > > This patch reverts the changes made in this commit:
> > >
> > >   deadcb36f49b ("drm/radeon: Use two-ended allocation by size, v2")
> > >
> > > That patch caused a regression on my system where the bottom of the
> > > screen flickers after my laptop goes thorough a suspend and resume.
> >
> > What kind of flicker is it? E.g. does it only affect X or also console,
> > does it flicker all the time or only when there is activity, what does
> > it look like, ...
> 
> It's kind of hard to describe it precisely, so I made a video.  :)
> 
> http://youtu.be/ESm9SMnr0do
> 
> It only affects X, not the console, and it seems to go away if you log
> out back to the login manager (I'm using GDM on Fedora 20) and back into
> your window manager.

Does a VT switch or forcing a dpms cycle (sleep 5; xset dpms force off) also 
fix it?  It doesn't look related to the patch in question at all.  Is the 
flickering 100% reproducible or does it only happen periodically?

Alex

> 
> I've tested with OpenBox, Gnome and KDE, and it happens in all three, so
> it doesn't appear to be related to the window manager.
> 
> It does appear to flicker more if you move the mouse, but it still does
> flicker occasionally if you aren't doing anything.

[PATCH v4 3/3] mmc: dw_mmc: Don't start command while data busy

[Addy Ke]

We should wait until unbusy before the next request.
But this does't need if the command is CMD13, which can access
SD Status register regardless of data busy.

Signed-off-by: Addy Ke 
---
Changes in v4:
- CMD13 doesn't need wait until unbusy.

 drivers/mmc/host/dw_mmc.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
index ac21863..692d97a 100644
--- a/drivers/mmc/host/dw_mmc.c
+++ b/drivers/mmc/host/dw_mmc.c
@@ -1076,6 +1076,10 @@ static void dw_mci_request(struct mmc_host *mmc, struct 
mmc_request *mrq)
 
WARN_ON(slot->mrq);
 
+   /* Wait until unbusy if the command isn't CMD13 */
+   if (mrq->cmd->opcode != MMC_SEND_STATUS)
+   dw_mci_wait_busy(slot);
+
/*
 * The check for card presence and queueing of the request must be
 * atomic, otherwise the card could be removed in between and the
-- 
1.8.3.2


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

[PATCH v4 2/3] mmc: dw_mmc: fix bug that cause 'Timeout sending command'

[Addy Ke]

Because of some uncertain factors, such as worse card or worse hardware,
DAT[3:0](the data lines) may be pulled down by card, and mmc controller
will be in busy state. This should not happend when mmc controller
send command to update card clocks. If this happends, mci_send_cmd will
be failed and we will get 'Timeout sending command', and then system will
be blocked. To avoid this, we need reset mmc controller.

Signed-off-by: Addy Ke 
Changes in v4:
- Retry to wait and reset all blocks until data unbusy.
  I have a sd card, which need retry 2 times to change to unbusy state.

---
 drivers/mmc/host/dw_mmc.c | 33 +
 1 file changed, 33 insertions(+)

diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
index 3472f9b..ac21863 100644
--- a/drivers/mmc/host/dw_mmc.c
+++ b/drivers/mmc/host/dw_mmc.c
@@ -100,6 +100,7 @@ struct idmac_desc {
 };
 #endif /* CONFIG_MMC_DW_IDMAC */
 
+static int dw_mci_card_busy(struct mmc_host *mmc);
 static bool dw_mci_reset(struct dw_mci *host);
 static bool dw_mci_ctrl_reset(struct dw_mci *host, u32 reset);
 
@@ -888,6 +889,36 @@ static void mci_send_cmd(struct dw_mci_slot *slot, u32 
cmd, u32 arg)
cmd, arg, cmd_status);
 }
 
+static void dw_mci_wait_busy(struct dw_mci_slot *slot)
+{
+   bool ret = true;
+   struct dw_mci *host = slot->host;
+   unsigned long timeout = jiffies + msecs_to_jiffies(500);
+
+   if (host->state == STATE_WAITING_CMD11_DONE)
+   return;
+
+   do {
+   do {
+   if (!dw_mci_card_busy(slot->mmc))
+   return;
+   usleep_range(50, 100);
+   } while (time_before(jiffies, timeout));
+
+   dev_err(host->dev, "Data busy (status %#x)\n",
+   mci_readl(slot->host, STATUS));
+
+   /*
+* Data busy, this should not happend when mmc controller
+* send command to update card clocks in non-volt-switch state.
+* If it happends, we should reset controller to avoid getting
+* "Timeout sending command".
+*/
+   ret = dw_mci_ctrl_reset(host, SDMMC_CTRL_ALL_RESET_FLAGS);
+
+   } while (!ret || dw_mci_card_busy(slot->mmc));
+}
+
 static void dw_mci_setup_bus(struct dw_mci_slot *slot, bool force_clkinit)
 {
struct dw_mci *host = slot->host;
@@ -896,6 +927,8 @@ static void dw_mci_setup_bus(struct dw_mci_slot *slot, bool 
force_clkinit)
u32 clk_en_a;
u32 sdmmc_cmd_bits = SDMMC_CMD_UPD_CLK | SDMMC_CMD_PRV_DAT_WAIT;
 
+   dw_mci_wait_busy(slot);
+
/* We must continue to set bit 28 in CMD until the change is complete */
if (host->state == STATE_WAITING_CMD11_DONE)
sdmmc_cmd_bits |= SDMMC_CMD_VOLT_SWITCH;
-- 
1.8.3.2


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

[PATCH v4 0/3] about data busy

[Addy Ke]

patch 1: This patch can fix bug that controller is still data busy after
 reset all blocks. After this patch, I still get data busy in
 set_ios().

patch 2: This patch fix bug 'Timeout sending command'. After patch1 and
 patch2, there is no mmc errors after:
 cd /sys/bus/platform/drivers/dwmmc_rockchip
 for i in $(seq 1 1); do
echo "" $i
echo ff0c.dwmmc > unbind
sleep .5
echo ff0c.dwmmc > bind
sleep 2
done
 
patch3: This patch fix bug that there is data busy before sdio send CMD53.
But This patch is necessary for sd and mmc too.

Addy Ke (3):
  mmc: dw_mmc: update clock after host reach a stable voltage
  mmc: dw_mmc: fix bug that cause 'Timeout sending command'
  mmc: dw_mmc: Don't start command while data busy

 drivers/mmc/host/dw_mmc.c | 41 -
 1 file changed, 40 insertions(+), 1 deletion(-)

-- 
1.8.3.2


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

[PATCH v4 1/3] mmc: dw_mmc: update clock after host reach a stable voltage

[Addy Ke]

As show in mmc_power_up(), in MMC_POWER_UP state, the voltage isn't
stable and we may get 'data busy' which can't be cleaned by resetting
all blocks. So we should not send command to update clock in this state.

Signed-off-by: Addy Ke 
---
 drivers/mmc/host/dw_mmc.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
index 4d2e3c2..3472f9b 100644
--- a/drivers/mmc/host/dw_mmc.c
+++ b/drivers/mmc/host/dw_mmc.c
@@ -1102,7 +1102,8 @@ static void dw_mci_set_ios(struct mmc_host *mmc, struct 
mmc_ios *ios)
drv_data->set_ios(slot->host, ios);
 
/* Slot specific timing and width adjustment */
-   dw_mci_setup_bus(slot, false);
+   if (ios->power_mode != MMC_POWER_UP)
+   dw_mci_setup_bus(slot, false);
 
if (slot->host->state == STATE_WAITING_CMD11_DONE && ios->clock != 0)
slot->host->state = STATE_IDLE;
-- 
1.8.3.2


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

Hsing Ning Industrial Company Ltd Required Your Service

[Hsing Ning Industrial Company Ltd]

Hsing Ning Industrial Company Ltd (HNICL), is in urgent need of a reputable 
company/firm or individual to serve as our financial coordinator in America and 
Canada. Precisely, Hsing Ning Industrial Company Ltd (HNICL) require you or 
your firm to be our company financial coordinator in your province, This will 
not affect your present occupation or location, It's a part time and full time 
job and pays well. Reply for more details

Thanks
Mr. Frank Chou
Hsing Ning Industrial Company Ltd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.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] ASoC: fsl-asoc-card: Add snd_soc_of_parse_audio_routing()

[Nicolin Chen]

On Sat, Feb 14, 2015 at 02:32:12PM +0900, Mark Brown wrote:
> On Fri, Feb 13, 2015 at 09:02:46PM -0800, Nicolin Chen wrote:
> > On Sat, Feb 14, 2015 at 01:31:53PM +0900, Mark Brown wrote:
> 
> > > How about having it just record that it should parse the given property
> > > when the table in the card is being handleed rather than overwrite that?
> 
> > You mean adding another pair of dapm_routes with num_dapm_routes for
> > Device Tree or something like that?
> 
> That should work, I had been thinking of just recording where to parse
> from and deferring the parse entirely.

Okay. I'll try both approaches and choose a comparatively neater one.

Thanks
Nicolin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.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] spi: xilinx: Use standard num-cs binding

[Mark Brown]

On Wed, Feb 11, 2015 at 12:07:20PM +0100, Michal Simek wrote:
> 2015-01-16 13:55 GMT+01:00 Michal Simek :

> > Use standard num-cs binding property and setup
> > "xlnx,num-ss-bits" as deprecated.

> Any update on this one?

Don't send content free quoted pings, they're just adding to the e-mail
volume and hence wasting people's time.


signature.asc
Description: Digital signature

[PATCH 4/5] Staging: gdm724x: code style improvements

[Tolga Ceylan]

In memory allocation (kzalloc, kmalloc) arguments
sizeof(struct foo) rewritten as sizeof(*foo_obj).

Signed-off-by: Tolga Ceylan 
---
 drivers/staging/gdm724x/gdm_mux.c |  8 
 drivers/staging/gdm724x/gdm_tty.c |  2 +-
 drivers/staging/gdm724x/gdm_usb.c | 10 +-
 3 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/drivers/staging/gdm724x/gdm_mux.c 
b/drivers/staging/gdm724x/gdm_mux.c
index b025a49..522f3cd 100644
--- a/drivers/staging/gdm724x/gdm_mux.c
+++ b/drivers/staging/gdm724x/gdm_mux.c
@@ -67,7 +67,7 @@ static struct mux_tx *alloc_mux_tx(int len)
 {
struct mux_tx *t = NULL;
 
-   t = kzalloc(sizeof(struct mux_tx), GFP_ATOMIC);
+   t = kzalloc(sizeof(*t), GFP_ATOMIC);
if (!t)
return NULL;
 
@@ -96,7 +96,7 @@ static struct mux_rx *alloc_mux_rx(void)
 {
struct mux_rx *r = NULL;
 
-   r = kzalloc(sizeof(struct mux_rx), GFP_KERNEL);
+   r = kzalloc(sizeof(*r), GFP_KERNEL);
if (!r)
return NULL;
 
@@ -529,11 +529,11 @@ static int gdm_mux_probe(struct usb_interface *intf,
if (bInterfaceNumber != 2)
return -ENODEV;
 
-   mux_dev = kzalloc(sizeof(struct mux_dev), GFP_KERNEL);
+   mux_dev = kzalloc(sizeof(*mux_dev), GFP_KERNEL);
if (!mux_dev)
return -ENOMEM;
 
-   tty_dev = kzalloc(sizeof(struct tty_dev), GFP_KERNEL);
+   tty_dev = kzalloc(sizeof(*tty_dev), GFP_KERNEL);
if (!tty_dev) {
ret = -ENOMEM;
goto err_free_mux;
diff --git a/drivers/staging/gdm724x/gdm_tty.c 
b/drivers/staging/gdm724x/gdm_tty.c
index b593525..3b9bf07 100644
--- a/drivers/staging/gdm724x/gdm_tty.c
+++ b/drivers/staging/gdm724x/gdm_tty.c
@@ -226,7 +226,7 @@ int register_lte_tty_device(struct tty_dev *tty_dev, struct 
device *device)
 
for (i = 0; i < TTY_MAX_COUNT; i++) {
 
-   gdm = kmalloc(sizeof(struct gdm), GFP_KERNEL);
+   gdm = kmalloc(sizeof(*gdm), GFP_KERNEL);
if (!gdm)
return -ENOMEM;
 
diff --git a/drivers/staging/gdm724x/gdm_usb.c 
b/drivers/staging/gdm724x/gdm_usb.c
index 36fe1b4..e81b266 100644
--- a/drivers/staging/gdm724x/gdm_usb.c
+++ b/drivers/staging/gdm724x/gdm_usb.c
@@ -92,7 +92,7 @@ static struct usb_tx *alloc_tx_struct(int len)
struct usb_tx *t = NULL;
int ret = 0;
 
-   t = kzalloc(sizeof(struct usb_tx), GFP_ATOMIC);
+   t = kzalloc(sizeof(*t), GFP_ATOMIC);
if (!t) {
ret = -ENOMEM;
goto out;
@@ -125,7 +125,7 @@ static struct usb_tx_sdu *alloc_tx_sdu_struct(void)
 {
struct usb_tx_sdu *t_sdu;
 
-   t_sdu = kzalloc(sizeof(struct usb_tx_sdu), GFP_KERNEL);
+   t_sdu = kzalloc(sizeof(*t_sdu), GFP_KERNEL);
if (!t_sdu)
return NULL;
 
@@ -183,7 +183,7 @@ static struct usb_rx *alloc_rx_struct(void)
struct usb_rx *r = NULL;
int ret = 0;
 
-   r = kmalloc(sizeof(struct usb_rx), GFP_KERNEL);
+   r = kmalloc(sizeof(*r), GFP_KERNEL);
if (!r) {
ret = -ENOMEM;
goto out;
@@ -829,11 +829,11 @@ static int gdm_usb_probe(struct usb_interface *intf,
return -ENODEV;
}
 
-   phy_dev = kzalloc(sizeof(struct phy_dev), GFP_KERNEL);
+   phy_dev = kzalloc(sizeof(*phy_dev), GFP_KERNEL);
if (!phy_dev)
return -ENOMEM;
 
-   udev = kzalloc(sizeof(struct lte_udev), GFP_KERNEL);
+   udev = kzalloc(sizeof(*udev), GFP_KERNEL);
if (!udev) {
ret = -ENOMEM;
goto err_udev;
-- 
2.3.0

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

[PATCH 5/5] Staging: gdm724x: code style improvements

[Tolga Ceylan]

Unnecessary blank lines removed

Signed-off-by: Tolga Ceylan 
---
 drivers/staging/gdm724x/gdm_endian.c | 1 -
 drivers/staging/gdm724x/gdm_mux.c| 5 -
 drivers/staging/gdm724x/gdm_tty.c| 1 -
 drivers/staging/gdm724x/gdm_tty.h| 1 -
 drivers/staging/gdm724x/hci_packet.h | 1 -
 5 files changed, 9 deletions(-)

diff --git a/drivers/staging/gdm724x/gdm_endian.c 
b/drivers/staging/gdm724x/gdm_endian.c
index f6cc90a..4044453 100644
--- a/drivers/staging/gdm724x/gdm_endian.c
+++ b/drivers/staging/gdm724x/gdm_endian.c
@@ -31,7 +31,6 @@ void gdm_set_endian(struct gdm_endian *ed, u8 dev_endian)
ed->host_ed = ENDIANNESS_LITTLE;
else
ed->host_ed = ENDIANNESS_BIG;
-
 }
 
 u16 gdm_cpu_to_dev16(struct gdm_endian *ed, u16 x)
diff --git a/drivers/staging/gdm724x/gdm_mux.c 
b/drivers/staging/gdm724x/gdm_mux.c
index 522f3cd..7584d7a 100644
--- a/drivers/staging/gdm724x/gdm_mux.c
+++ b/drivers/staging/gdm724x/gdm_mux.c
@@ -48,7 +48,6 @@ static const struct usb_device_id id_table[] = {
{}
 };
 
-
 MODULE_DEVICE_TABLE(usb, id_table);
 
 static int packet_type_to_index(u16 packetType)
@@ -150,7 +149,6 @@ static void put_rx_struct(struct rx_cxt *rx, struct mux_rx 
*r)
spin_unlock_irqrestore(>free_list_lock, flags);
 }
 
-
 static int up_to_host(struct mux_rx *r)
 {
struct mux_dev *mux_dev = (struct mux_dev *)r->mux_dev;
@@ -477,7 +475,6 @@ static void release_usb(struct mux_dev *mux_dev)
spin_unlock_irqrestore(>to_host_lock, flags);
 }
 
-
 static int init_usb(struct mux_dev *mux_dev)
 {
struct mux_rx *r;
@@ -615,7 +612,6 @@ static int gdm_mux_suspend(struct usb_interface *intf, 
pm_message_t pm_msg)
 
mux_dev->usb_state = PM_SUSPEND;
 
-
spin_lock_irqsave(>submit_list_lock, flags);
list_for_each_entry_safe(r, r_next, >rx_submit_list,
 rx_submit_list) {
@@ -663,7 +659,6 @@ static struct usb_driver gdm_mux_driver = {
 
 static int __init gdm_usb_mux_init(void)
 {
-
mux_rx_wq = create_workqueue("mux_rx_wq");
if (!mux_rx_wq) {
pr_err("work queue create fail\n");
diff --git a/drivers/staging/gdm724x/gdm_tty.c 
b/drivers/staging/gdm724x/gdm_tty.c
index 3b9bf07..60b52a3 100644
--- a/drivers/staging/gdm724x/gdm_tty.c
+++ b/drivers/staging/gdm724x/gdm_tty.c
@@ -225,7 +225,6 @@ int register_lte_tty_device(struct tty_dev *tty_dev, struct 
device *device)
int j;
 
for (i = 0; i < TTY_MAX_COUNT; i++) {
-
gdm = kmalloc(sizeof(*gdm), GFP_KERNEL);
if (!gdm)
return -ENOMEM;
diff --git a/drivers/staging/gdm724x/gdm_tty.h 
b/drivers/staging/gdm724x/gdm_tty.h
index 297438b..195c590 100644
--- a/drivers/staging/gdm724x/gdm_tty.h
+++ b/drivers/staging/gdm724x/gdm_tty.h
@@ -17,7 +17,6 @@
 #include 
 #include 
 
-
 #define TTY_MAX_COUNT  2
 
 #define MAX_ISSUE_NUM 3
diff --git a/drivers/staging/gdm724x/hci_packet.h 
b/drivers/staging/gdm724x/hci_packet.h
index 7fba8a6..46e0fc4 100644
--- a/drivers/staging/gdm724x/hci_packet.h
+++ b/drivers/staging/gdm724x/hci_packet.h
@@ -89,5 +89,4 @@ struct hci_connect_ind {
u32 connect;
 } __packed;
 
-
 #endif /* _HCI_PACKET_H_ */
-- 
2.3.0

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

[PATCH 2/5] Staging: gdm724x: code style improvements

[Tolga Ceylan]

Alignment should match open paranthesis cases corrected

Signed-off-by: Tolga Ceylan 
---
 drivers/staging/gdm724x/gdm_lte.c   | 32 
 drivers/staging/gdm724x/gdm_lte.h   | 14 +++---
 drivers/staging/gdm724x/gdm_mux.c   |  5 +++--
 drivers/staging/gdm724x/gdm_usb.c   | 18 +-
 drivers/staging/gdm724x/netlink_k.c |  3 ++-
 drivers/staging/gdm724x/netlink_k.h |  4 ++--
 6 files changed, 39 insertions(+), 37 deletions(-)

diff --git a/drivers/staging/gdm724x/gdm_lte.c 
b/drivers/staging/gdm724x/gdm_lte.c
index dab5ba7..2c3931b 100644
--- a/drivers/staging/gdm724x/gdm_lte.c
+++ b/drivers/staging/gdm724x/gdm_lte.c
@@ -162,11 +162,11 @@ static int gdm_lte_emulate_arp(struct sk_buff *skb_in, 
u32 nic_type)
skb_reserve(skb_out, NET_IP_ALIGN);
 
memcpy(skb_put(skb_out, mac_header_len), mac_header_data,
-   mac_header_len);
+  mac_header_len);
memcpy(skb_put(skb_out, sizeof(struct arphdr)), arp_out,
-   sizeof(struct arphdr));
+  sizeof(struct arphdr));
memcpy(skb_put(skb_out, sizeof(struct arpdata)), arp_data_out,
-   sizeof(struct arpdata));
+  sizeof(struct arpdata));
 
skb_out->protocol = ((struct ethhdr *)mac_header_data)->h_proto;
skb_out->dev = skb_in->dev;
@@ -300,13 +300,13 @@ static int gdm_lte_emulate_ndp(struct sk_buff *skb_in, 
u32 nic_type)
memcpy(_out, ipv6_in, sizeof(struct ipv6hdr));
memcpy(ipv6_out.saddr.in6_u.u6_addr8, _address, 16);
memcpy(ipv6_out.daddr.in6_u.u6_addr8,
-   ipv6_in->saddr.in6_u.u6_addr8, 16);
+  ipv6_in->saddr.in6_u.u6_addr8, 16);
ipv6_out.payload_len = htons(sizeof(struct icmp6hdr) +
sizeof(struct neighbour_advertisement));
 
memcpy(icmp_na, _out, sizeof(struct icmp6hdr));
memcpy(icmp_na + sizeof(struct icmp6hdr), ,
-   sizeof(struct neighbour_advertisement));
+  sizeof(struct neighbour_advertisement));
 
icmp6_out.icmp6_cksum = icmp6_checksum(_out,
(u16 *)icmp_na, sizeof(icmp_na));
@@ -326,13 +326,13 @@ static int gdm_lte_emulate_ndp(struct sk_buff *skb_in, 
u32 nic_type)
skb_reserve(skb_out, NET_IP_ALIGN);
 
memcpy(skb_put(skb_out, mac_header_len), mac_header_data,
-   mac_header_len);
+  mac_header_len);
memcpy(skb_put(skb_out, sizeof(struct ipv6hdr)), _out,
-   sizeof(struct ipv6hdr));
+  sizeof(struct ipv6hdr));
memcpy(skb_put(skb_out, sizeof(struct icmp6hdr)), _out,
-   sizeof(struct icmp6hdr));
+  sizeof(struct icmp6hdr));
memcpy(skb_put(skb_out, sizeof(struct neighbour_advertisement)), ,
-   sizeof(struct neighbour_advertisement));
+  sizeof(struct neighbour_advertisement));
 
skb_out->protocol = ((struct ethhdr *)mac_header_data)->h_proto;
skb_out->dev = skb_in->dev;
@@ -530,7 +530,7 @@ static int gdm_lte_event_send(struct net_device *dev, char 
*buf, int len)
 }
 
 static void gdm_lte_event_rcv(struct net_device *dev, u16 type,
-   void *msg, int len)
+ void *msg, int len)
 {
struct nic *nic = netdev_priv(dev);
 
@@ -572,7 +572,7 @@ static u8 find_dev_index(u32 nic_type)
 }
 
 static void gdm_lte_netif_rx(struct net_device *dev, char *buf,
-   int len, int flagged_nic_type)
+int len, int flagged_nic_type)
 {
u32 nic_type;
struct nic *nic;
@@ -697,9 +697,9 @@ static void gdm_lte_multi_sdu_pkt(struct phy_dev *phy_dev, 
char *buf, int len)
u8 index;
 
hci_len = gdm_dev16_to_cpu(phy_dev->get_endian(phy_dev->priv_dev),
-   multi_sdu->len);
+  multi_sdu->len);
num_packet = gdm_dev16_to_cpu(phy_dev->get_endian(phy_dev->priv_dev),
-   multi_sdu->num_packet);
+ multi_sdu->num_packet);
 
for (i = 0; i < num_packet; i++) {
sdu = (struct sdu *)data;
@@ -724,7 +724,7 @@ static void gdm_lte_multi_sdu_pkt(struct phy_dev *phy_dev, 
char *buf, int len)
if (index < MAX_NIC_TYPE) {
dev = phy_dev->dev[index];
gdm_lte_netif_rx(dev, (char *)sdu->data,
-   (int)(hci_len - 12), nic_type);
+(int)(hci_len - 12), nic_type);
} else {
pr_err("rx sdu invalid nic_type :%x\n", nic_type);
}
@@ -772,7 +772,7 @@ static int gdm_lte_receive_pkt(struct phy_dev *phy_dev, 
char *buf, int len)
return ret;
 
cmd_evt = 

Re: [PATCH] ASoC: fsl-asoc-card: Add snd_soc_of_parse_audio_routing()

[Mark Brown]

On Fri, Feb 13, 2015 at 09:02:46PM -0800, Nicolin Chen wrote:
> On Sat, Feb 14, 2015 at 01:31:53PM +0900, Mark Brown wrote:

> > How about having it just record that it should parse the given property
> > when the table in the card is being handleed rather than overwrite that?

> You mean adding another pair of dapm_routes with num_dapm_routes for
> Device Tree or something like that?

That should work, I had been thinking of just recording where to parse
from and deferring the parse entirely.


signature.asc
Description: Digital signature

[PATCH 1/5] Staging: gdm724x: code style improvements

[Tolga Ceylan]

Corrections based on checkpatch.pl with --strict.
Added missing spaces between operators.

Signed-off-by: Tolga Ceylan 
---
 drivers/staging/gdm724x/gdm_lte.c   |  6 +++---
 drivers/staging/gdm724x/gdm_mux.c   |  4 ++--
 drivers/staging/gdm724x/gdm_mux.h   |  4 ++--
 drivers/staging/gdm724x/gdm_tty.c   |  2 +-
 drivers/staging/gdm724x/gdm_usb.c   |  6 +++---
 drivers/staging/gdm724x/gdm_usb.h   |  6 +++---
 drivers/staging/gdm724x/netlink_k.c | 10 +-
 7 files changed, 19 insertions(+), 19 deletions(-)

diff --git a/drivers/staging/gdm724x/gdm_lte.c 
b/drivers/staging/gdm724x/gdm_lte.c
index 7c4a77b..dab5ba7 100644
--- a/drivers/staging/gdm724x/gdm_lte.c
+++ b/drivers/staging/gdm724x/gdm_lte.c
@@ -724,12 +724,12 @@ static void gdm_lte_multi_sdu_pkt(struct phy_dev 
*phy_dev, char *buf, int len)
if (index < MAX_NIC_TYPE) {
dev = phy_dev->dev[index];
gdm_lte_netif_rx(dev, (char *)sdu->data,
-   (int)(hci_len-12), nic_type);
+   (int)(hci_len - 12), nic_type);
} else {
pr_err("rx sdu invalid nic_type :%x\n", nic_type);
}
 
-   data += ((hci_len+3) & 0xfffc) + HCI_HEADER_SIZE;
+   data += ((hci_len + 3) & 0xfffc) + HCI_HEADER_SIZE;
}
 }
 
@@ -850,7 +850,7 @@ static void form_mac_address(u8 *dev_addr, u8 *nic_src, u8 
*nic_dest,
/* The last byte of the mac address
 * should be less than or equal to 0xFC
 */
-   dev_addr[ETH_ALEN-1] += index;
+   dev_addr[ETH_ALEN - 1] += index;
 
/* Create random nic src and copy the first
 * 3 bytes to be the same as dev_addr
diff --git a/drivers/staging/gdm724x/gdm_mux.c 
b/drivers/staging/gdm724x/gdm_mux.c
index d1ab996..826b537 100644
--- a/drivers/staging/gdm724x/gdm_mux.c
+++ b/drivers/staging/gdm724x/gdm_mux.c
@@ -391,8 +391,8 @@ static int gdm_mux_send(void *priv_dev, void *data, int 
len, int tty_index,
mux_header->payload_size = __cpu_to_le32((u32)len);
mux_header->packet_type = __cpu_to_le16(packet_type[tty_index]);
 
-   memcpy(t->buf+MUX_HEADER_SIZE, data, len);
-   memset(t->buf+MUX_HEADER_SIZE+len, 0, dummy_cnt);
+   memcpy(t->buf + MUX_HEADER_SIZE, data, len);
+   memset(t->buf + MUX_HEADER_SIZE + len, 0, dummy_cnt);
 
t->len = total_len;
t->callback = cb;
diff --git a/drivers/staging/gdm724x/gdm_mux.h 
b/drivers/staging/gdm724x/gdm_mux.h
index 3d50383..0871b8f 100644
--- a/drivers/staging/gdm724x/gdm_mux.h
+++ b/drivers/staging/gdm724x/gdm_mux.h
@@ -27,8 +27,8 @@
 
 #define START_FLAG 0xA512485A
 #define MUX_HEADER_SIZE 14
-#define MUX_TX_MAX_SIZE (1024*10)
-#define MUX_RX_MAX_SIZE (1024*30)
+#define MUX_TX_MAX_SIZE (1024 * 10)
+#define MUX_RX_MAX_SIZE (1024 * 30)
 #define AT_PKT_TYPE 0xF011
 #define DM_PKT_TYPE 0xF010
 
diff --git a/drivers/staging/gdm724x/gdm_tty.c 
b/drivers/staging/gdm724x/gdm_tty.c
index 001348c..f8c18a9 100644
--- a/drivers/staging/gdm724x/gdm_tty.c
+++ b/drivers/staging/gdm724x/gdm_tty.c
@@ -193,7 +193,7 @@ static int gdm_tty_write(struct tty_struct *tty, const 
unsigned char *buf,
sending_len = remain > MUX_TX_MAX_SIZE ? MUX_TX_MAX_SIZE :
 remain;
gdm_tty_send(gdm,
-(void *)(buf+sent_len),
+(void *)(buf + sent_len),
 sending_len,
 gdm->index,
 gdm_tty_send_complete,
diff --git a/drivers/staging/gdm724x/gdm_usb.c 
b/drivers/staging/gdm724x/gdm_usb.c
index d2a3b35..f4a2824 100644
--- a/drivers/staging/gdm724x/gdm_usb.c
+++ b/drivers/staging/gdm724x/gdm_usb.c
@@ -347,7 +347,7 @@ static int init_usb(struct lte_udev *udev)
tx->avail_count++;
}
 
-   for (i = 0; i < MAX_RX_SUBMIT_COUNT*2; i++) {
+   for (i = 0; i < MAX_RX_SUBMIT_COUNT * 2; i++) {
r = alloc_rx_struct();
if (r == NULL) {
ret = -ENOMEM;
@@ -576,7 +576,7 @@ static int send_tx_packet(struct usb_device *usbdev, struct 
usb_tx *t, u32 len)
 {
int ret = 0;
 
-   if (!(len%512))
+   if (!(len % 512))
len++;
 
usb_fill_bulk_urb(t->urb,
@@ -744,7 +744,7 @@ static int gdm_usb_sdu_send(void *priv_dev, void *data, int 
len,
} else {
send_len = len - ETH_HLEN;
send_len += SDU_PARAM_LEN;
-   memcpy(sdu->data, data+ETH_HLEN, len-ETH_HLEN);
+   memcpy(sdu->data, data + ETH_HLEN, len - ETH_HLEN);
}
 
sdu->len = gdm_cpu_to_dev16(>gdm_ed, send_len);
diff --git a/drivers/staging/gdm724x/gdm_usb.h 
b/drivers/staging/gdm724x/gdm_usb.h
index e6486e7..ffb3d99 100644
--- a/drivers/staging/gdm724x/gdm_usb.h
+++ b/drivers/staging/gdm724x/gdm_usb.h
@@ -26,10 +26,10 @@
 

[PATCH 3/5] Staging: gdm724x: code style improvements

[Tolga Ceylan]

Comparisons such as if (x == NULL) rewritten as if (!x)

Signed-off-by: Tolga Ceylan 
---
 drivers/staging/gdm724x/gdm_lte.c |  6 +++---
 drivers/staging/gdm724x/gdm_mux.c |  4 ++--
 drivers/staging/gdm724x/gdm_tty.c |  2 +-
 drivers/staging/gdm724x/gdm_usb.c | 14 +++---
 4 files changed, 13 insertions(+), 13 deletions(-)

diff --git a/drivers/staging/gdm724x/gdm_lte.c 
b/drivers/staging/gdm724x/gdm_lte.c
index 2c3931b..7a86184 100644
--- a/drivers/staging/gdm724x/gdm_lte.c
+++ b/drivers/staging/gdm724x/gdm_lte.c
@@ -775,7 +775,7 @@ static int gdm_lte_receive_pkt(struct phy_dev *phy_dev, 
char *buf, int len)
   hci->cmd_evt);
 
dev = phy_dev->dev[0];
-   if (dev == NULL)
+   if (!dev)
return 0;
 
switch (cmd_evt) {
@@ -889,7 +889,7 @@ int register_lte_device(struct phy_dev *phy_dev,
/* Allocate netdev */
net = alloc_netdev(sizeof(struct nic), pdn_dev_name,
   NET_NAME_UNKNOWN, ether_setup);
-   if (net == NULL) {
+   if (!net) {
pr_err("alloc_netdev failed\n");
ret = -ENOMEM;
goto err;
@@ -938,7 +938,7 @@ void unregister_lte_device(struct phy_dev *phy_dev)
 
for (index = 0; index < MAX_NIC_TYPE; index++) {
net = phy_dev->dev[index];
-   if (net == NULL)
+   if (!net)
continue;
 
unregister_netdev(net);
diff --git a/drivers/staging/gdm724x/gdm_mux.c 
b/drivers/staging/gdm724x/gdm_mux.c
index 9b5e6b8..b025a49 100644
--- a/drivers/staging/gdm724x/gdm_mux.c
+++ b/drivers/staging/gdm724x/gdm_mux.c
@@ -495,7 +495,7 @@ static int init_usb(struct mux_dev *mux_dev)
 
for (i = 0; i < MAX_ISSUE_NUM * 2; i++) {
r = alloc_mux_rx();
-   if (r == NULL) {
+   if (!r) {
ret = -ENOMEM;
break;
}
@@ -665,7 +665,7 @@ static int __init gdm_usb_mux_init(void)
 {
 
mux_rx_wq = create_workqueue("mux_rx_wq");
-   if (mux_rx_wq == NULL) {
+   if (!mux_rx_wq) {
pr_err("work queue create fail\n");
return -1;
}
diff --git a/drivers/staging/gdm724x/gdm_tty.c 
b/drivers/staging/gdm724x/gdm_tty.c
index f8c18a9..b593525 100644
--- a/drivers/staging/gdm724x/gdm_tty.c
+++ b/drivers/staging/gdm724x/gdm_tty.c
@@ -88,7 +88,7 @@ static int gdm_tty_install(struct tty_driver *driver, struct 
tty_struct *tty)
 
mutex_lock(_table_lock);
gdm = gdm_table[i][j];
-   if (gdm == NULL) {
+   if (!gdm) {
mutex_unlock(_table_lock);
return -ENODEV;
}
diff --git a/drivers/staging/gdm724x/gdm_usb.c 
b/drivers/staging/gdm724x/gdm_usb.c
index 786c177..36fe1b4 100644
--- a/drivers/staging/gdm724x/gdm_usb.c
+++ b/drivers/staging/gdm724x/gdm_usb.c
@@ -338,7 +338,7 @@ static int init_usb(struct lte_udev *udev)
 
for (i = 0; i < MAX_NUM_SDU_BUF; i++) {
t_sdu = alloc_tx_sdu_struct();
-   if (t_sdu == NULL) {
+   if (!t_sdu) {
ret = -ENOMEM;
goto fail;
}
@@ -349,7 +349,7 @@ static int init_usb(struct lte_udev *udev)
 
for (i = 0; i < MAX_RX_SUBMIT_COUNT * 2; i++) {
r = alloc_rx_struct();
-   if (r == NULL) {
+   if (!r) {
ret = -ENOMEM;
goto fail;
}
@@ -681,7 +681,7 @@ static void do_tx(struct work_struct *work)
}
 
t = alloc_tx_struct(TX_BUF_SIZE);
-   if (t == NULL) {
+   if (!t) {
spin_unlock_irqrestore(>lock, flags);
return;
}
@@ -731,7 +731,7 @@ static int gdm_usb_sdu_send(void *priv_dev, void *data, int 
len,
t_sdu = get_tx_sdu_struct(tx, _spc);
spin_unlock_irqrestore(>lock, flags);
 
-   if (t_sdu == NULL) {
+   if (!t_sdu) {
pr_err("sdu send - free list empty\n");
return TX_NO_SPC;
}
@@ -781,7 +781,7 @@ static int gdm_usb_hci_send(void *priv_dev, void *data, int 
len,
}
 
t = alloc_tx_struct(len);
-   if (t == NULL) {
+   if (!t) {
pr_err("hci_send - out of memory\n");
return -ENOMEM;
}
@@ -1005,11 +1005,11 @@ static int __init gdm_usb_lte_init(void)
}
 
usb_tx_wq = create_workqueue("usb_tx_wq");
-   if (usb_tx_wq == NULL)
+   if (!usb_tx_wq)
return -1;
 
usb_rx_wq = create_workqueue("usb_rx_wq");
-   if (usb_rx_wq == NULL)
+   if (!usb_rx_wq)
return -1;
 
return usb_register(_usb_lte_driver);
-- 
2.3.0

--
To unsubscribe from this list: send the line "unsubscribe 

Re: [PATCH v2] regmap-irq: set IRQF_ONESHOT flag to ensure IRQ request

[Mark Brown]

On Wed, Feb 11, 2015 at 04:37:57PM +0100, Valentin Rothberg wrote:
> Since commit 1c6c69525b40eb76de8adf039409722015927dc3 ("genirq: Reject
> bogus threaded irq requests") threaded IRQs without a primary handler
> need to be requested with IRQF_ONESHOT, otherwise the request will fail.

Applied, thanks.


signature.asc
Description: Digital signature

Re: [PATCH] ASoC: fsl-asoc-card: Add snd_soc_of_parse_audio_routing()

[Nicolin Chen]

On Sat, Feb 14, 2015 at 01:31:53PM +0900, Mark Brown wrote:
> On Thu, Feb 12, 2015 at 01:30:02PM -0800, Nicolin Chen wrote:
> 
> > This patch adds snd_soc_of_parse_audio_routing() to get dapm routes
> > via Device Tree. Because snd_soc_of_parse_audio_routing() overrides
> > dpam_routes, we use snd_soc_dapm_add_routes() to append the original
> > build-in DPCM routes instead of linking them to dpam_routes directly.
> 
> It seems better to make the helper function play nicely with existing
> DAPM routes in the card rather than have to rearrange things like this.

Yes, that would be better.

> How about having it just record that it should parse the given property
> when the table in the card is being handleed rather than overwrite that?

You mean adding another pair of dapm_routes with num_dapm_routes for
Device Tree or something like that?

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

Re: [RFC 13/16] mm/cma: populate ZONE_CMA and use this zone when GFP_HIGHUSERMOVABLE

[Gioh Kim]

2015-02-12 오후 4:32에 Joonsoo Kim 이(가) 쓴 글:
> Until now, reserved pages for CMA are managed altogether with normal
> page in the same zone. This approach has numorous problems and fixing
> them isn't easy. To fix this situation, ZONE_CMA is introduced in
> previous patch, but, not yet populated. This patch implement population
> of ZONE_CMA by stealing reserved pages from normal zones. This stealing
> break one uncertain assumption on zone, that is, zone isn't overlapped.
> In the early of this series, some check is inserted to every zone's span
> iterator to handle zone overlap so there would be no problem with
> this assumption break.
> 
> To utilize this zone, user should use GFP_HIGHUSERMOVABLE, because

I think it might be typo of GFP_HIGHUSER_MOVABLE.

> these pages are only applicable for movable type and ZONE_CMA could
> contain highmem.
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.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] spi: spidev: only use up TX/RX bounce buffer space when needed

[Mark Brown]

On Thu, Feb 12, 2015 at 12:13:08PM +, Ian Abbott wrote:
> Devices have separate, pre-allocated TX and RX bounce buffers of fixed
> size.  Currently, each transfer uses up space in both buffers even if
> the user-supplied no TX data or no RX space.  Change it to only use up
> space in the TX and RX bounce buffers as required.

This is a bit hard to parse.  I think you're talking about buffers in
spidev here but it's unclear and you've not described in what way you're
changing the code and we do currently only seem to copy data when the
user has asked for it.

> Since dummy transfers with no user-supplied TX data and no user-supplied
> RX space will no longer use up space in the bounce buffers, limit the
> overall SPI message length to INT_MAX instead of the buffer size.

That doesn't seem to follow at all.  No mention has been made of
eliminating the buffers entirely or otherwise ensuring that we can
handle transfers of any length - not using the buffer for transmit isn't
going to make the receive buffer any bigger and indeed...

>   if (u_tmp->rx_buf) {
> + rx_total += k_tmp->len;
> + if (rx_total > bufsiz) {
> + status = -EMSGSIZE;
> + goto done;
> + }

...we do still seem to be limited to the buffer size here as one would
expect?

Basically I'm not entirely clear what this change is supposed to be
doing or what the expected benefit is.  I *think* the goal is to allow
multi-transfer messages with a mix of unidirectional transfers to be
larger but the changelog needs to be clearer and it's not 100% clear why
we'd bother to check for INT_MAX.


signature.asc
Description: Digital signature

Re: linux-next: Tree for Feb 13 (runtime failures and 'non-zero nr_pmds' messages)

[Guenter Roeck]

Hi Stephen,

On 02/13/2015 03:37 PM, Stephen Rothwell wrote:

Hi Guenter,

On Fri, 13 Feb 2015 10:54:28 -0800 Guenter Roeck  wrote:


I see a number of runtime failures with this version.
It affects alpha, mips64, ppc64, and x86_64.
Symptom is always the same. There are lots of

BUG: non-zero nr_pmds on freeing mm: X (where X is 1..4)

messages in the log, and the affected VMs don't reboot.

I don't see the problem in curent mainline, nor in mmotm.
Bisect points to "Merge branch 'akpm-current/current'",
which isn't really helpful.

Not sure if this is a bad merge resolution, so just take this
as a heads-up for now.


Yours is the second report overnight (see attached).  Almost certainly
a bad merge resolution on my part (its a bit hard when Andrew get part
of his patch set merged by Linus :-()


And now Fengguang's tests caught it as well.


I will fix up the merge on Monday (unless Andrew gets more stuff merged
or updates mmotm for me).

Sorry about that.



No worries. Good news is that test coverage is getting better.

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] ASoC: omap-hdmi-audio: Add missing error check for devm_kzalloc

[Mark Brown]

On Thu, Feb 12, 2015 at 02:38:02PM +0530, Kiran Padwal wrote:
> This patch add a missing check on the return value of devm_kzalloc,
> which would cause a NULL pointer dereference in a OOM situation.

Applied, thanks.


signature.asc
Description: Digital signature

Re: [PATCH] ASoC: fsl-asoc-card: Add snd_soc_of_parse_audio_routing()

[Mark Brown]

On Thu, Feb 12, 2015 at 01:30:02PM -0800, Nicolin Chen wrote:

> This patch adds snd_soc_of_parse_audio_routing() to get dapm routes
> via Device Tree. Because snd_soc_of_parse_audio_routing() overrides
> dpam_routes, we use snd_soc_dapm_add_routes() to append the original
> build-in DPCM routes instead of linking them to dpam_routes directly.

It seems better to make the helper function play nicely with existing
DAPM routes in the card rather than have to rearrange things like this.
How about having it just record that it should parse the given property
when the table in the card is being handleed rather than overwrite that?


signature.asc
Description: Digital signature

Re: [PATCH 0/4] ASoC: samsung: clean up references to outdated Kconfig symbols

[Mark Brown]

On Wed, Feb 11, 2015 at 10:21:38AM +0100, Paul Bolle wrote:

> TL;DR: what exactly should I resend and when?

This is disappointing; you're someone who's been contributing for quite
some time now, I'd really expect you to be faimilar with the process of
submitting patches and able to identify answers to your questions.

> > What's posted doesn't apply against -next.

> That's because of trivial conflicts with commit a59aa180ea56 ("ASoC:
> samsung: Replace depends on REGMAP_I2C with depends on I2C"). That
> commit landed in next-20150127 (ie, eight days after I sent this short
> series). I guess I resolved these conflicts in the local version of
> these patches and promptly forgot about them, as they were so trivial.

For something like this I'm just not even going to look at what's
required to fix up by hand, sorry.

> > As ever submit against the tree listed in MAINTAINERS

> >git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next

> Which is not entirely obvious, since this series only touches files
> below sound/soc/samsung/. That directory is mentioned in MAINTAINERS
> under "ARM/SAMSUNG EXYNOS ARM ARCHITECTURES" and under "SAMSUNG AUDIO
> (ASoC) DRIVERS". (Why does that directory need two entries?) Neither
> entry mention a repository.

Of course neither of those entries list me either yet you managed to
figure out that you should send the patch to me.  The same process that
helps you identify that things should be submitted to the subsystem
maintainers should allow you to identify where they're likely to try to
apply changes.  Or simply looking at how other similar patches get
merged.

> And now I wonder what I should resend: the three patches 2/4, 3/4, and
> 4/4 with the trivial conflicts resolved or the entire series? And when
> do you prefer I resend?

Again this is something I'd really expect you to be familiar with.  As
ever if there are changes you would like to see integrated into the
kernel then please submit them using the normal patch submission
process.


signature.asc
Description: Digital signature

Re: [PATCH] drm/radeon: Fix regression with suspend/resume

[Ross Zwisler]

On Fri, 2015-02-13 at 11:41 +0900, Michel Dänzer wrote:
> On 13.02.2015 05:30, Ross Zwisler wrote:
> > This patch reverts the changes made in this commit:
> > 
> >   deadcb36f49b ("drm/radeon: Use two-ended allocation by size, v2")
> > 
> > That patch caused a regression on my system where the bottom of the
> > screen flickers after my laptop goes thorough a suspend and resume.
> 
> What kind of flicker is it? E.g. does it only affect X or also console,
> does it flicker all the time or only when there is activity, what does
> it look like, ...

It's kind of hard to describe it precisely, so I made a video.  :)

http://youtu.be/ESm9SMnr0do

It only affects X, not the console, and it seems to go away if you log
out back to the login manager (I'm using GDM on Fedora 20) and back into
your window manager.

I've tested with OpenBox, Gnome and KDE, and it happens in all three, so
it doesn't appear to be related to the window manager.

It does appear to flicker more if you move the mouse, but it still does
flicker occasionally if you aren't doing anything.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] x86: Prevent oops with >16 memory controllers

[Daniel J Blueman]

When ECC interrupts occur on memory controllers after EDAC_MAX_MCS (16), the
kernel fatally dereferences unallocated structures [1]; this occurs on at
least NumaConnect systems.

Minimally fix by checking if a memory controller info structure is allocated;
candidate for stable.

Signed-off-by: Daniel J Blueman 

-- [1]

BUG: unable to handle kernel NULL pointer dereference at 0320
IP: [] decode_bus_error+0x2f/0x2b0
PGD 2f8b5a3067 PUD 2f8b5a2067 PMD 0
Oops:  [#2] SMP
Modules linked in:
CPU: 224 PID: 11930 Comm: stream_c.exe.gn Tainted: G   D3.19.0 #1
Hardware name: Supermicro H8QGL/H8QGL, BIOS 3.5b01/28/2015
task: 8807dbfb8c00 ti: 8807dd16c000 task.ti: 8807dd16c000
RIP: 0010:[] [] decode_bus_error+0x2f/0x2b0
RSP: :8907dfc03c48 EFLAGS: 00010297
RAX: 0001 RBX: 9c67400010080a13 RCX: 1dc6
RDX: 1dc61dc6 RSI: 8907dfc03df0 RDI: 001c
RBP: 8907dfc03ce8 R08:  R09: 0022
R10: 891fffa30380 R11: 001cfc90 R12: 0008
R13:  R14: 001c R15: 9c6740001000
FS: 7fa97ee18700() GS:8907dfc0() knlGS:
CS: 0010 DS:  ES:  CR0: 80050033
CR2: 0320 CR3: 003f889b8000 CR4: 000407e0
Stack:
  8907dfc03df0 0008 9c67400010080a13
 001c 9c6740001000 8907dfc03c88 810e4f9a
 8907dfc03ce8 81b375b9  0010
Call Trace:
 
 [] ? vprintk_default+0x1a/0x20
 [] ? printk+0x41/0x43
 [] amd_decode_mce+0x58f/0x8e0
 [] notifier_call_chain+0x4d/0x80
 [] atomic_notifier_call_chain+0x15/0x20
 [] mce_log+0x1d/0x130
 [] machine_check_poll+0x194/0x260
 [] mce_timer_fn+0x116/0x140
 [] ? mce_cpu_restart+0x40/0x40
 [] call_timer_fn.isra.29+0x17/0x80
 [] run_timer_softirq+0x18b/0x220
 [] __do_softirq+0xf9/0x200
 [] irq_exit+0x76/0xa0
 [] smp_apic_timer_interrupt+0x41/0x50
 [] apic_timer_interrupt+0x67/0x70
 
 [] ? down_read_trylock+0x15/0x20
 [] __do_page_fault+0xbb/0x4c0
 [] ? __schedule+0x25a/0x850
 [] do_page_fault+0xc/0x10
 [] page_fault+0x1f/0x30
---
 drivers/edac/amd64_edac.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/edac/amd64_edac.c b/drivers/edac/amd64_edac.c
index 17638d7..baccc0e 100644
--- a/drivers/edac/amd64_edac.c
+++ b/drivers/edac/amd64_edac.c
@@ -2175,7 +2175,7 @@ static void __log_bus_error(struct mem_ctl_info *mci, 
struct err_info *err,
 static inline void decode_bus_error(int node_id, struct mce *m)
 {
struct mem_ctl_info *mci = mcis[node_id];
-   struct amd64_pvt *pvt = mci->pvt_info;
+   struct amd64_pvt *pvt;
u8 ecc_type = (m->status >> 45) & 0x3;
u8 xec = XEC(m->status, 0x1f);
u16 ec = EC(m->status);
@@ -2190,6 +2190,11 @@ static inline void decode_bus_error(int node_id, struct 
mce *m)
if (xec && xec != F10_NBSL_EXT_ERR_ECC)
return;
 
+   /* Unable to decode on memory controllers after EDAC_MAX_MCS, as no mci 
is allocated */
+   if (!mci)
+   return;
+   pvt = mci->pvt_info;
+
memset(, 0, sizeof(err));
 
sys_addr = get_error_address(pvt, m);
-- 
1.9.1

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

[PATCH] staging: nvec: Make nvec_write_sync return result by parameter

[Evan Hauck]

As outlined in the TODO file, nvec_write_sync was modified to return an error
code instead of NULL on failure, and return the nvec_msg as a parameter.

Signed-off-by: Evan Hauck 
---
 drivers/staging/nvec/TODO   |  2 --
 drivers/staging/nvec/nvec.c | 37 +
 drivers/staging/nvec/nvec.h |  5 +++--
 3 files changed, 24 insertions(+), 20 deletions(-)

diff --git a/drivers/staging/nvec/TODO b/drivers/staging/nvec/TODO
index e5ae42a..e4d85d9 100644
--- a/drivers/staging/nvec/TODO
+++ b/drivers/staging/nvec/TODO
@@ -3,6 +3,4 @@ ToDo list (incomplete, unordered)
- move half of the nvec init stuff to i2c-tegra.c
- move event handling to nvec_events
- finish suspend/resume support
-   - modifiy the sync_write method to return the received
- message in a variable (and return the error code).
- add support for more device implementations
diff --git a/drivers/staging/nvec/nvec.c b/drivers/staging/nvec/nvec.c
index 120b70d..47ef013 100644
--- a/drivers/staging/nvec/nvec.c
+++ b/drivers/staging/nvec/nvec.c
@@ -288,46 +288,53 @@ EXPORT_SYMBOL(nvec_write_async);
  * @nvec: An  nvec_chip
  * @data: The data to write
  * @size: The size of @data
+ * @result: The resulting message
  *
  * This is similar to nvec_write_async(), but waits for the
  * request to be answered before returning. This function
  * uses a mutex and can thus not be called from e.g.
  * interrupt handlers.
  *
- * Returns: A pointer to the response message on success,
+ * Returns in *result: A pointer to the response message on success,
  * %NULL on failure. Free with nvec_msg_free() once no longer
  * used.
+ *
+ * Returns: 0 on success, a negative error code on failure. If a failure
+ * occurred, the nvec driver may print an error.
  */
-struct nvec_msg *nvec_write_sync(struct nvec_chip *nvec,
-   const unsigned char *data, short size)
+int nvec_write_sync(struct nvec_chip *nvec,
+   const unsigned char *data, short size,
+   struct nvec_msg **msg)
 {
-   struct nvec_msg *msg;
+   int err;
 
mutex_lock(>sync_write_mutex);
 
nvec->sync_write_pending = (data[1] << 8) + data[0];
 
-   if (nvec_write_async(nvec, data, size) < 0) {
+   err = nvec_write_async(nvec, data, size);
+   if (err < 0) {
mutex_unlock(>sync_write_mutex);
-   return NULL;
+   return err;
}
 
dev_dbg(nvec->dev, "nvec_sync_write: 0x%04x\n",
nvec->sync_write_pending);
-   if (!(wait_for_completion_timeout(>sync_write,
-   msecs_to_jiffies(2000 {
+   err = wait_for_completion_timeout(>sync_write,
+   msecs_to_jiffies(2000));
+   if (!err) {
dev_warn(nvec->dev, "timeout waiting for sync write to 
complete\n");
mutex_unlock(>sync_write_mutex);
-   return NULL;
+   return err;
}
 
dev_dbg(nvec->dev, "nvec_sync_write: pong!\n");
 
-   msg = nvec->last_sync_msg;
+   *msg = nvec->last_sync_msg;
 
mutex_unlock(>sync_write_mutex);
 
-   return msg;
+   return 0;
 }
 EXPORT_SYMBOL(nvec_write_sync);
 
@@ -879,9 +886,7 @@ static int tegra_nvec_probe(struct platform_device *pdev)
pm_power_off = nvec_power_off;
 
/* Get Firmware Version */
-   msg = nvec_write_sync(nvec, get_firmware_version, 2);
-
-   if (msg) {
+   if (!nvec_write_sync(nvec, get_firmware_version, 2, )) {
dev_warn(nvec->dev, "ec firmware version %02x.%02x.%02x / 
%02x\n",
msg->data[4], msg->data[5], msg->data[6], msg->data[7]);
 
@@ -935,8 +940,8 @@ static int nvec_suspend(struct device *dev)
/* keep these sync or you'll break suspend */
nvec_toggle_global_events(nvec, false);
 
-   msg = nvec_write_sync(nvec, ap_suspend, sizeof(ap_suspend));
-   nvec_msg_free(nvec, msg);
+   if (!nvec_write_sync(nvec, ap_suspend, sizeof(ap_suspend), ))
+   nvec_msg_free(nvec, msg);
 
nvec_disable_i2c_slave(nvec);
 
diff --git a/drivers/staging/nvec/nvec.h b/drivers/staging/nvec/nvec.h
index e271375..00d099a 100644
--- a/drivers/staging/nvec/nvec.h
+++ b/drivers/staging/nvec/nvec.h
@@ -168,8 +168,9 @@ struct nvec_chip {
 extern int nvec_write_async(struct nvec_chip *nvec, const unsigned char *data,
 short size);
 
-extern struct nvec_msg *nvec_write_sync(struct nvec_chip *nvec,
-   const unsigned char *data, short size);
+extern int nvec_write_sync(struct nvec_chip *nvec,
+  const unsigned char *data, short size,
+  struct nvec_msg **result);
 
 extern int nvec_register_notifier(struct nvec_chip *nvec,
  struct notifier_block *nb,
-- 
2.3.0

--
To unsubscribe from this list: send the line 

[PATCH] perf tools: Work around lack of sched_getcpu in glibc < 2.6.

[Vinson Lee]

From: Vinson Lee 

This patch fixes this build error with glibc < 2.6.

  CC   util/cloexec.o
cc1: warnings being treated as errors
util/cloexec.c: In function ‘perf_flag_probe’:
util/cloexec.c:24: error: implicit declaration of function
‘sched_getcpu’
util/cloexec.c:24: error: nested extern declaration of ‘sched_getcpu’
make: *** [util/cloexec.o] Error 1

Cc: sta...@vger.kernel.org # 3.18+
Signed-off-by: Vinson Lee 
---
 tools/perf/util/cloexec.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/tools/perf/util/cloexec.c b/tools/perf/util/cloexec.c
index 47b78b3..3738924 100644
--- a/tools/perf/util/cloexec.c
+++ b/tools/perf/util/cloexec.c
@@ -7,6 +7,12 @@
 
 static unsigned long flag = PERF_FLAG_FD_CLOEXEC;
 
+#ifdef __GLIBC_PREREQ
+#if __GLIBC_PREREQ(2, 6)
+#define HAVE_SCHED_GETCPU
+#endif
+#endif
+
 static int perf_flag_probe(void)
 {
/* use 'safest' configuration as used in perf_evsel__fallback() */
@@ -21,9 +27,13 @@ static int perf_flag_probe(void)
pid_t pid = -1;
char sbuf[STRERR_BUFSIZE];
 
+#ifdef HAVE_SCHED_GETCPU
cpu = sched_getcpu();
if (cpu < 0)
cpu = 0;
+#else
+   cpu = 0;
+#endif
 
while (1) {
/* check cloexec flag */
-- 
1.8.2.1

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

chelsio: Use a more common const struct pci_device_id foo[] style

[Joe Perches]

Chelsio code shares a pci_device_table from an #include file.
Make the include guard simpler and make the arrays const.

Reduces data by moving tables to text.

Removed unnecessary macros:
o CH_PCI_DEVICE_ID_TABLE_DEFINE_BEGIN
o CH_PCI_DEVICE_ID_TABLE_DEFINE_END
o CH_PCI_ID_TABLE_ENTRY (moved to the .h file)
Added new macro define:
o CH_PCI_ID_TABLE_ENTRY_DATA

  text data bss dec hex filename
  50550 923 172   51645c9bd 
drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.o.new
  469354531 172   51638c9b6 
drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.o.old
  27864 355   8   282276e43 
drivers/net/ethernet/chelsio/cxgb4vf/cxgb4vf_main.o.new
  260722203   8   282836e7b 
drivers/net/ethernet/chelsio/cxgb4vf/cxgb4vf_main.o.old
   9734 450  24   1020827e0 drivers/scsi/csiostor/csio_init.o.new
   79422242  24   1020827e0 drivers/scsi/csiostor/csio_init.o.old

Signed-off-by: Joe Perches 
---
 drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c| 17 --
 drivers/net/ethernet/chelsio/cxgb4/t4_pci_id_tbl.h | 38 --
 .../net/ethernet/chelsio/cxgb4vf/cxgb4vf_main.c| 10 ++
 drivers/scsi/csiostor/csio_init.c  | 11 +++
 4 files changed, 27 insertions(+), 49 deletions(-)

diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c 
b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
index a22cf93..8a01eeb 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
@@ -123,23 +123,18 @@ struct filter_entry {
 
 /* Macros needed to support the PCI Device ID Table ...
  */
-#define CH_PCI_DEVICE_ID_TABLE_DEFINE_BEGIN \
-   static struct pci_device_id cxgb4_pci_tbl[] = {
-#define CH_PCI_DEVICE_ID_FUNCTION 0x4
+
+#define CH_PCI_DEVICE_ID_FUNCTION  0x4
+#define CH_PCI_ID_TABLE_ENTRY_DATA 4
 
 /* Include PCI Device IDs for both PF4 and PF0-3 so our PCI probe() routine is
  * called for both.
  */
-#define CH_PCI_DEVICE_ID_FUNCTION2 0x0
-
-#define CH_PCI_ID_TABLE_ENTRY(devid) \
-   {PCI_VDEVICE(CHELSIO, (devid)), 4}
-
-#define CH_PCI_DEVICE_ID_TABLE_DEFINE_END \
-   { 0, } \
-   }
+#define CH_PCI_DEVICE_ID_FUNCTION2 0x0
 
+static const struct pci_device_id cxgb4_pci_tbl[] = {
 #include "t4_pci_id_tbl.h"
+};
 
 #define FW4_FNAME "cxgb4/t4fw.bin"
 #define FW5_FNAME "cxgb4/t5fw.bin"
diff --git a/drivers/net/ethernet/chelsio/cxgb4/t4_pci_id_tbl.h 
b/drivers/net/ethernet/chelsio/cxgb4/t4_pci_id_tbl.h
index ddfb5b8..f648091 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/t4_pci_id_tbl.h
+++ b/drivers/net/ethernet/chelsio/cxgb4/t4_pci_id_tbl.h
@@ -39,9 +39,6 @@
  *
  * The macros are:
  *
- * CH_PCI_DEVICE_ID_TABLE_DEFINE_BEGIN
- *   -- Used to start the definition of the PCI ID Table.
- *
  * CH_PCI_DEVICE_ID_FUNCTION
  *   -- The PCI Function Number to use in the PCI Device ID Table.  "0"
  *   -- for drivers attaching to PF0-3, "4" for drivers attaching to PF4,
@@ -51,25 +48,17 @@
  *   -- If defined, create a PCI Device ID Table with both
  *   -- CH_PCI_DEVICE_ID_FUNCTION and CH_PCI_DEVICE_ID_FUNCTION2 populated.
  *
- * CH_PCI_ID_TABLE_ENTRY(DeviceID)
+ * CH_PCI_ID_TABLE_ENTRY_DATA(DeviceID)
  *   -- Used for the individual PCI Device ID entries.  Note that we will
  *   -- be adding a trailing comma (",") after all of the entries (and
  *   -- between the pairs of entries if CH_PCI_DEVICE_ID_FUNCTION2 is defined).
- *
- * CH_PCI_DEVICE_ID_TABLE_DEFINE_END
- *   -- Used to finish the definition of the PCI ID Table.  Note that we
- *   -- will be adding a trailing semi-colon (";") here.
  */
-#ifdef CH_PCI_DEVICE_ID_TABLE_DEFINE_BEGIN
 
 #ifndef CH_PCI_DEVICE_ID_FUNCTION
 #error CH_PCI_DEVICE_ID_FUNCTION not defined!
 #endif
-#ifndef CH_PCI_ID_TABLE_ENTRY
-#error CH_PCI_ID_TABLE_ENTRY not defined!
-#endif
-#ifndef CH_PCI_DEVICE_ID_TABLE_DEFINE_END
-#error CH_PCI_DEVICE_ID_TABLE_DEFINE_END not defined!
+#ifndef CH_PCI_ID_TABLE_ENTRY_DATA
+#error CH_PCI_ID_TABLE_ENTRY_DATA not defined!
 #endif
 
 /* T4 and later ASICs use a PCI Device ID scheme of 0xVFPP where:
@@ -81,19 +70,22 @@
  * We use this consistency in order to create the proper PCI Device IDs
  * for the specified CH_PCI_DEVICE_ID_FUNCTION.
  */
+
+#define CH_PCI_ID_TABLE_ENTRY(devid)   \
+   { PCI_VDEVICE(CHELSIO, devid), CH_PCI_ID_TABLE_ENTRY_DATA }
+
 #ifndef CH_PCI_DEVICE_ID_FUNCTION2
-#define CH_PCI_ID_TABLE_FENTRY(devid) \
-   CH_PCI_ID_TABLE_ENTRY((devid) | \
+#define CH_PCI_ID_TABLE_FENTRY(devid)  \
+   CH_PCI_ID_TABLE_ENTRY((devid) | \
  ((CH_PCI_DEVICE_ID_FUNCTION) << 8))
 #else
-#define CH_PCI_ID_TABLE_FENTRY(devid) \
-   CH_PCI_ID_TABLE_ENTRY((devid) | \
- ((CH_PCI_DEVICE_ID_FUNCTION) << 8)), \
-   CH_PCI_ID_TABLE_ENTRY((devid) | \
+#define 

[PATCH] ion: improve ion_phys error message

[Mitchel Humpherys]

Clients often get confused when ion_phys errors out due to some heap
being used that they didn't expect.  Add the heap name and heap type to
the error message to make it more obvious.

Signed-off-by: Mitchel Humpherys 
---
 drivers/staging/android/ion/ion.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/android/ion/ion.c 
b/drivers/staging/android/ion/ion.c
index 296d347660fc..966b7fdc9ecf 100644
--- a/drivers/staging/android/ion/ion.c
+++ b/drivers/staging/android/ion/ion.c
@@ -566,8 +566,8 @@ int ion_phys(struct ion_client *client, struct ion_handle 
*handle,
buffer = handle->buffer;
 
if (!buffer->heap->ops->phys) {
-   pr_err("%s: ion_phys is not implemented by this heap.\n",
-  __func__);
+   pr_err("%s: ion_phys is not implemented by this heap (name=%s, 
type=%d).\n",
+   __func__, buffer->heap->name, buffer->heap->type);
mutex_unlock(>lock);
return -ENODEV;
}
-- 
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

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

[no subject]

[Leanne Armstrong]

You were selected for QATAR Foundation 2015 beneficiaries contact 
RodFalusi(rodrigofalus...@yahoo.co.za)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.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 01/11] ARM: vexpress: use ARM_CPU_SUSPEND if needed

[Liviu Dudau]

On Sat, Feb 14, 2015 at 06:55:05AM +0800, Nicolas Pitre wrote:
> On Fri, 13 Feb 2015, Liviu Dudau wrote:
> 
> > On Thu, Feb 12, 2015 at 07:42:33PM +, Arnd Bergmann wrote:
> > > The vexpress tc2 power management code calls mcpm_loopback, which
> > > is only available if ARM_CPU_SUSPEND is enabled, otherwise we
> > > get a link error:
> > > 
> > > arch/arm/mach-vexpress/built-in.o: In function `tc2_pm_init':
> > > arch/arm/mach-vexpress/tc2_pm.c:389: undefined reference to 
> > > `mcpm_loopback'
> > 
> > Arnd,
> > 
> > We are having reports of TC2 not booting with MCPM enabled. Lorenzo
> > was investigating this but then headed for Linaro Connect this week,
> > so we don't have yet a resolution. Can this patch be postponed for
> > a later -rc?
> 
> Can you share those reports?  I did boot my TC2 with v3.19-rc7 before 
> leaving for Linaro Connect and it just worked.
> 
> Regardless, this patch is about a build fix and doesn't change any 
> functionality, so I wouldn't postpone it.
> 

OK. Acked-by: Liviu Dudau 

Best regards,
Liviu

> 
> 
> > 
> > Best regards,
> > Liviu
> > 
> > 
> > > 
> > > This explicitly selects ARM_CPU_SUSPEND like other platforms that
> > > need it.
> > > 
> > > Signed-off-by: Arnd Bergmann 
> > > Fixes: 3592d7e002438 ("ARM: 8082/1: TC2: test the MCPM loopback during 
> > > boot")
> > > Cc: Nicolas Pitre 
> > > Cc: Kevin Hilman 
> > > Cc: Liviu Dudau 
> > > Cc: Sudeep Holla 
> > > Cc: Lorenzo Pieralisi 
> > > ---
> > >  arch/arm/mach-vexpress/Kconfig | 1 +
> > >  1 file changed, 1 insertion(+)
> > > 
> > > diff --git a/arch/arm/mach-vexpress/Kconfig 
> > > b/arch/arm/mach-vexpress/Kconfig
> > > index d6b16d9a7838..3c2509b4b694 100644
> > > --- a/arch/arm/mach-vexpress/Kconfig
> > > +++ b/arch/arm/mach-vexpress/Kconfig
> > > @@ -73,6 +73,7 @@ config ARCH_VEXPRESS_TC2_PM
> > >   depends on MCPM
> > >   select ARM_CCI
> > >   select ARCH_VEXPRESS_SPC
> > > + select ARM_CPU_SUSPEND
> > >   help
> > > Support for CPU and cluster power management on Versatile Express
> > > with a TC2 (A15x2 A7x3) big.LITTLE core tile.
> > > -- 
> > > 2.1.0.rc2
> > > 
> > > 
> > 
> > -- 
> > 
> > | I would like to |
> > | fix the world,  |
> > | but they're not |
> > | giving me the   |
> >  \ source 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/
> > 
> > 


-- 
---
   .oooO
   (   )
\ (  Oooo.
 \_) (   )
  ) /
 (_/

 One small step
   for me ...

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

[PATCH] thermal: Introduce dummy functions when thermal is not defined

[Nishanth Menon]

When CONFIG_THERMAL is not enabled, it is better to introduce
equivalent dummy functions in the exported header than to
introduce #ifdeffery in drivers using the function.

This will prevent issues such as that reported in:
http://www.spinics.net/lists/linux-next/msg31573.html

While at it switch over to IS_ENABLED for thermal macros
to allow for thermal framework to be built as framework
and relevant APIs be usable by relevant drivers as a result.

Reported-by: Guenter Roeck 
Signed-off-by: Nishanth Menon 
---

based on next-20150213 tag.

Note: there are a few "CHECK: Alignment should match open parenthesis"
checkpatch warnings which I ignored since these are pure dummy
functions anyways.

 include/linux/thermal.h |   56 +--
 1 file changed, 54 insertions(+), 2 deletions(-)

diff --git a/include/linux/thermal.h b/include/linux/thermal.h
index fc52e307efab..5eac316490ea 100644
--- a/include/linux/thermal.h
+++ b/include/linux/thermal.h
@@ -314,6 +314,8 @@ void thermal_zone_of_sensor_unregister(struct device *dev,
 }
 
 #endif
+
+#if IS_ENABLED(CONFIG_THERMAL)
 struct thermal_zone_device *thermal_zone_device_register(const char *, int, 
int,
void *, struct thermal_zone_device_ops *,
const struct thermal_zone_params *, int, int);
@@ -340,8 +342,58 @@ struct thermal_instance *get_thermal_instance(struct 
thermal_zone_device *,
struct thermal_cooling_device *, int);
 void thermal_cdev_update(struct thermal_cooling_device *);
 void thermal_notify_framework(struct thermal_zone_device *, int);
-
-#ifdef CONFIG_NET
+#else
+static inline struct thermal_zone_device *thermal_zone_device_register(
+   const char *type, int trips, int mask, void *devdata,
+   struct thermal_zone_device_ops *ops,
+   const struct thermal_zone_params *tzp,
+   int passive_delay, int polling_delay)
+{ return ERR_PTR(-ENODEV); }
+static inline void thermal_zone_device_unregister(
+   struct thermal_zone_device *tz)
+{ }
+static inline int thermal_zone_bind_cooling_device(
+   struct thermal_zone_device *tz, int trip,
+   struct thermal_cooling_device *cdev,
+   unsigned long upper, unsigned long lower)
+{ return -ENODEV; }
+static inline int thermal_zone_unbind_cooling_device(
+   struct thermal_zone_device *tz, int trip,
+   struct thermal_cooling_device *cdev)
+{ return -ENODEV; }
+static inline void thermal_zone_device_update(struct thermal_zone_device *tz)
+{ }
+static inline struct thermal_cooling_device *
+thermal_cooling_device_register(char *type, void *devdata,
+   const struct thermal_cooling_device_ops *ops)
+{ return ERR_PTR(-ENODEV); }
+static inline struct thermal_cooling_device *
+thermal_of_cooling_device_register(struct device_node *np,
+   char *type, void *devdata, const struct thermal_cooling_device_ops *ops)
+{ return ERR_PTR(-ENODEV); }
+static inline void thermal_cooling_device_unregister(
+   struct thermal_cooling_device *cdev)
+{ }
+static inline struct thermal_zone_device *thermal_zone_get_zone_by_name(
+   const char *name)
+{ return ERR_PTR(-ENODEV); }
+static inline int thermal_zone_get_temp(
+   struct thermal_zone_device *tz, unsigned long *temp)
+{ return -ENODEV; }
+static inline int get_tz_trend(struct thermal_zone_device *tz, int trip)
+{ return -ENODEV; }
+static inline struct thermal_instance *
+get_thermal_instance(struct thermal_zone_device *tz,
+   struct thermal_cooling_device *cdev, int trip)
+{ return ERR_PTR(-ENODEV); }
+static inline void thermal_cdev_update(struct thermal_cooling_device *cdev)
+{ }
+static inline void thermal_notify_framework(struct thermal_zone_device *tz,
+   int trip)
+{ }
+#endif /* CONFIG_THERMAL */
+
+#if defined(CONFIG_NET) && IS_ENABLED(CONFIG_THERMAL)
 extern int thermal_generate_netlink_event(struct thermal_zone_device *tz,
enum events event);
 #else
-- 
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/

[akpm merge] BUG: non-zero nr_pmds on freeing mm: 2

[Fengguang Wu]

Hi Stephen,

0day kernel testing robot got the below dmesg and the first bad commit is

git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master

commit 8fe7fba50596a8efb6e1ef15b1b4890f95eeffcd
Merge: 2ef44b3 d07b956
Author: Stephen Rothwell 
AuthorDate: Fri Feb 13 15:56:51 2015 +1100
Commit: Stephen Rothwell 
CommitDate: Fri Feb 13 15:56:51 2015 +1100

Merge branch 'akpm-current/current'

Conflicts:
arch/x86/include/asm/pgtable_64.h
include/linux/memcontrol.h
include/linux/mm.h
include/linux/slab.h
include/linux/swapops.h
kernel/fork.c
lib/Makefile
mm/memcontrol.c
mm/mprotect.c
mm/slab.h
mm/slab_common.c
mm/swap.c
scripts/module-common.lds

+++++---+
|| 2ef44b3a9e | d07b956c65 | 8fe7fba505 | 
next-20150213 |
+++++---+
| boot_successes | 60 | 60 | 0  | 0 
|
| boot_failures  | 0  | 0  | 20 | 
14|
| BUG:non-zero_nr_pmds_on_freeing_mm | 0  | 0  | 20 | 
14|
+++++---+

[2.209695] debug: unmapping init [mem 0x88000ff75000-0x88000fff]
[2.210862] debug: unmapping init [mem 0x8800103d1000-0x8800103f]
[2.217056] random: init urandom read with 3 bits of entropy available
[2.219092] BUG: non-zero nr_pmds on freeing mm: 2
[2.221865] BUG: non-zero nr_pmds on freeing mm: 3
[2.224047] BUG: non-zero nr_pmds on freeing mm: 2
[2.225538] hostname (100) used greatest stack depth: 14200 bytes left
[2.226392] BUG: non-zero nr_pmds on freeing mm: 4
[2.227118] mount (97) used greatest stack depth: 14104 bytes left
[2.227811] BUG: non-zero nr_pmds on freeing mm: 3
[2.228896] BUG: non-zero nr_pmds on freeing mm: 3
[2.230337] BUG: non-zero nr_pmds on freeing mm: 2
[2.231197] BUG: non-zero nr_pmds on freeing mm: 3
[2.233237] BUG: non-zero nr_pmds on freeing mm: 3
[2.234339] BUG: non-zero nr_pmds on freeing mm: 3
[2.235530] BUG: non-zero nr_pmds on freeing mm: 2
[2.237687] BUG: non-zero nr_pmds on freeing mm: 4
[2.240279] BUG: non-zero nr_pmds on freeing mm: 4
[2.241549] BUG: non-zero nr_pmds on freeing mm: 3
[2.242726] BUG: non-zero nr_pmds on freeing mm: 3
[2.243792] BUG: non-zero nr_pmds on freeing mm: 3
[2.244839] BUG: non-zero nr_pmds on freeing mm: 2
[2.245741] BUG: non-zero nr_pmds on freeing mm: 4
[2.246546] BUG: non-zero nr_pmds on freeing mm: 3
/bin/sh: /proc/self/fd/9: No such file or directory
[2.249348] BUG: non-zero nr_pmds on freeing mm: 4
[2.250126] BUG: non-zero nr_pmds on freeing mm: 3
[2.251983] BUG: non-zero nr_pmds on freeing mm: 4
[2.25] BUG: non-zero nr_pmds on freeing mm: 2
[2.255435] BUG: non-zero nr_pmds on freeing mm: 3
[2.256551] BUG: non-zero nr_pmds on freeing mm: 3
[2.259066] BUG: non-zero nr_pmds on freeing mm: 3
[2.260070] BUG: non-zero nr_pmds on freeing mm: 4
[2.260977] BUG: non-zero nr_pmds on freeing mm: 4
[2.262336] BUG: non-zero nr_pmds on freeing mm: 2
[2.264123] sh (122) used greatest stack depth: 13992 bytes left
[2.264831] BUG: non-zero nr_pmds on freeing mm: 4
[2.266065] BUG: non-zero nr_pmds on freeing mm: 2
/bin/sh: /proc/self/fd/9: No such file or directory
[2.268783] BUG: non-zero nr_pmds on freeing mm: 4
[2.269971] BUG: non-zero nr_pmds on freeing mm: 2
/bin/sh: /proc/self/fd/9: No such file or directory
[2.272452] BUG: non-zero nr_pmds on freeing mm: 4

Elapsed time: 5
qemu-system-x86_64 -cpu kvm64 -enable-kvm -kernel 
/kernel/x86_64-randconfig-n0-02131024/8fe7fba50596a8efb6e1ef15b1b4890f95eeffcd/vmlinuz-3.19.0-g8fe7fba
 -append 'hung_task_panic=1 earlyprintk=ttyS0,115200 rd.udev.log-priority=err 
systemd.log_target=journal systemd.log_level=warning debug apic=debug 
sysrq_always_enabled rcupdate.rcu_cpu_stall_timeout=100 panic=-1 
softlockup_panic=1 nmi_watchdog=panic oops=panic load_ramdisk=2 
prompt_ramdisk=0 console=ttyS0,115200 console=tty0 vga=normal  root=/dev/ram0 
rw 
link=/kbuild-tests/run-queue/kvm/x86_64-randconfig-n0-02131024/next:master:8fe7fba50596a8efb6e1ef15b1b4890f95eeffcd:bisect-linux-7/.vmlinuz-8fe7fba50596a8efb6e1ef15b1b4890f95eeffcd-20150213172638-7-client7
 branch=next/master 
BOOT_IMAGE=/kernel/x86_64-randconfig-n0-02131024/8fe7fba50596a8efb6e1ef15b1b4890f95eeffcd/vmlinuz-3.19.0-g8fe7fba
 drbd.minor_count=8'  -initrd /kernel-tests/initrd/quantal-core-x86_64.cgz -m 
320 -smp 2 -net nic,vlan=1,model=e1000 -net user,vlan=1 -boot order=nc 
-no-reboot -watchdog i6300esb -rtc base=localtime -pidfile 
/dev/shm/kboot/pid

[PATCH v3] ARM: smp: Only expose /sys/.../cpuX/online if hotpluggable

[Stephen Boyd]

Writes to /sys/.../cpuX/online fail if we determine the platform
doesn't support hotplug for that CPU. Furthermore, if the cpu_die
op isn't specified the system hangs when we try to offline a CPU
and it comes right back online unexpectedly. Let's figure this
stuff out before we make the sysfs nodes so that the online file
doesn't even exist if it isn't (at least sometimes) possible to
hotplug the CPU.

Add a new cpu_can_disable op and repoint all cpu_disable
implementations at it because all current users use the op to
indicate if a CPU can be hotplugged or not in a static fashion.
With PSCI we may need to introduce a cpu_disable op so that the
secure OS can be migrated off the CPU we're trying to hotplug.
In this case, the cpu_can_disable op will indicate that all CPUs
are hotpluggable by returning 1, but the cpu_disable op will make
a PSCI migration call and occasionally fail, denying the hotplug
of a CPU. This shouldn't be any worse than x86 where we may
indicate that all CPUs are hotpluggable but occasionally we can't
offline a CPU due to check_irq_vectors_for_cpu_disable() failing
to find a CPU to move vectors to.

Cc: Mark Rutland 
Cc: Nicolas Pitre 
Cc: Dave Martin 
Cc: Simon Horman 
Cc: Magnus Damm 
Cc: 
Signed-off-by: Stephen Boyd 
---

Changes since v2:
 * Left cpu_disable op in place
 * Split out shmobile function deletion

 arch/arm/common/mcpm_platsmp.c   | 12 
 arch/arm/include/asm/smp.h   | 10 ++
 arch/arm/kernel/setup.c  |  2 +-
 arch/arm/kernel/smp.c| 15 ++-
 arch/arm/mach-shmobile/common.h  |  2 +-
 arch/arm/mach-shmobile/platsmp.c |  4 ++--
 arch/arm/mach-shmobile/smp-r8a7790.c |  2 +-
 arch/arm/mach-shmobile/smp-r8a7791.c |  2 +-
 arch/arm/mach-shmobile/smp-sh73a0.c  |  2 +-
 9 files changed, 35 insertions(+), 16 deletions(-)

diff --git a/arch/arm/common/mcpm_platsmp.c b/arch/arm/common/mcpm_platsmp.c
index 92e54d7c6f46..dc91ed04c25a 100644
--- a/arch/arm/common/mcpm_platsmp.c
+++ b/arch/arm/common/mcpm_platsmp.c
@@ -65,14 +65,10 @@ static int mcpm_cpu_kill(unsigned int cpu)
return !mcpm_wait_for_cpu_powerdown(pcpu, pcluster);
 }
 
-static int mcpm_cpu_disable(unsigned int cpu)
+static int mcpm_cpu_can_disable(unsigned int cpu)
 {
-   /*
-* We assume all CPUs may be shut down.
-* This would be the hook to use for eventual Secure
-* OS migration requests as described in the PSCI spec.
-*/
-   return 0;
+   /* We assume all CPUs may be shut down. */
+   return 1;
 }
 
 static void mcpm_cpu_die(unsigned int cpu)
@@ -92,7 +88,7 @@ static struct smp_operations __initdata mcpm_smp_ops = {
.smp_secondary_init = mcpm_secondary_init,
 #ifdef CONFIG_HOTPLUG_CPU
.cpu_kill   = mcpm_cpu_kill,
-   .cpu_disable= mcpm_cpu_disable,
+   .cpu_can_disable= mcpm_cpu_can_disable,
.cpu_die= mcpm_cpu_die,
 #endif
 };
diff --git a/arch/arm/include/asm/smp.h b/arch/arm/include/asm/smp.h
index 18f5a554134f..525c006fdf7c 100644
--- a/arch/arm/include/asm/smp.h
+++ b/arch/arm/include/asm/smp.h
@@ -104,6 +104,7 @@ struct smp_operations {
 #ifdef CONFIG_HOTPLUG_CPU
int  (*cpu_kill)(unsigned int cpu);
void (*cpu_die)(unsigned int cpu);
+   int  (*cpu_can_disable)(unsigned int cpu);
int  (*cpu_disable)(unsigned int cpu);
 #endif
 #endif
@@ -123,4 +124,13 @@ struct of_cpu_method {
  */
 extern void smp_set_ops(struct smp_operations *);
 
+#ifdef CONFIG_HOTPLUG_CPU
+extern int platform_can_hotplug_cpu(unsigned int cpu);
+#else
+static inline int platform_can_hotplug_cpu(unsigned int cpu)
+{
+   return 0;
+}
+#endif
+
 #endif /* ifndef __ASM_ARM_SMP_H */
diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index 715ae19bc7c8..c61c09defc78 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -974,7 +974,7 @@ static int __init topology_init(void)
 
for_each_possible_cpu(cpu) {
struct cpuinfo_arm *cpuinfo = _cpu(cpu_data, cpu);
-   cpuinfo->cpu.hotpluggable = 1;
+   cpuinfo->cpu.hotpluggable = platform_can_hotplug_cpu(cpu);
register_cpu(>cpu, cpu);
}
 
diff --git a/arch/arm/kernel/smp.c b/arch/arm/kernel/smp.c
index fe0386c751b2..152f65ef0494 100644
--- a/arch/arm/kernel/smp.c
+++ b/arch/arm/kernel/smp.c
@@ -179,13 +179,26 @@ static int platform_cpu_disable(unsigned int cpu)
if (smp_ops.cpu_disable)
return smp_ops.cpu_disable(cpu);
 
+   return 0;
+}
+
+int platform_can_hotplug_cpu(unsigned int cpu)
+{
+   /* cpu_die must be specified to support hotplug */
+   if (!smp_ops.cpu_die)
+   return 0;
+
+   if (smp_ops.cpu_can_disable)
+   return smp_ops.cpu_can_disable(cpu);
+
/*
 * By default, allow disabling all CPUs except the first one,
 * since this is special on a lot of platforms, e.g. 

[PATCH] ARM: shmobile: Remove redundant cpu_disable implementation

[Stephen Boyd]

By default only the non-boot CPUs can be hotplugged if the
smp_operations structure doesn't have the cpu_disable function
pointer set. r8a7779_cpu_disable() implements the same logic,
only non-boot CPUs can be hotplugged, so it's redundant to
override the default behavior.

Signed-off-by: Stephen Boyd 
---
 arch/arm/mach-shmobile/smp-r8a7779.c | 7 ---
 1 file changed, 7 deletions(-)

diff --git a/arch/arm/mach-shmobile/smp-r8a7779.c 
b/arch/arm/mach-shmobile/smp-r8a7779.c
index 3f761f839043..b45206f93ddf 100644
--- a/arch/arm/mach-shmobile/smp-r8a7779.c
+++ b/arch/arm/mach-shmobile/smp-r8a7779.c
@@ -124,19 +124,12 @@ static int r8a7779_cpu_kill(unsigned int cpu)
 
return 0;
 }
-
-static int r8a7779_cpu_disable(unsigned int cpu)
-{
-   /* only CPU1->3 have power domains, do not allow hotplug of CPU0 */
-   return cpu == 0 ? -EPERM : 0;
-}
 #endif /* CONFIG_HOTPLUG_CPU */
 
 struct smp_operations r8a7779_smp_ops  __initdata = {
.smp_prepare_cpus   = r8a7779_smp_prepare_cpus,
.smp_boot_secondary = r8a7779_boot_secondary,
 #ifdef CONFIG_HOTPLUG_CPU
-   .cpu_disable= r8a7779_cpu_disable,
.cpu_die= shmobile_smp_scu_cpu_die,
.cpu_kill   = r8a7779_cpu_kill,
 #endif
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

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

Re: linux-next: Tree for Feb 13 (iio/magnetometer/ak8975.c)

[Randy Dunlap]

On 02/13/15 16:32, Randy Dunlap wrote:
> On 02/12/15 21:56, Stephen Rothwell wrote:
>> Hi all,
>>
>> Please do not add any material destined for v3.21 to your linux-next
>> included trees until after v3.20-rc1 has been released.
>>
>> Changes since 20150212:
> 
> on i386:  when CONFIG_I2C is not enabled:

Caused by AK09911 selecting AK8975 but AK09911 does not depend on I2C.

> ../drivers/iio/magnetometer/ak8975.c: In function 'ak8975_who_i_am':
> ../drivers/iio/magnetometer/ak8975.c:393:2: error: implicit declaration of 
> function 'i2c_smbus_read_i2c_block_data' 
> [-Werror=implicit-function-declaration]
>   ret = i2c_smbus_read_i2c_block_data(client, AK09912_REG_WIA1,
>   ^
> ../drivers/iio/magnetometer/ak8975.c: In function 'ak8975_set_mode':
> ../drivers/iio/magnetometer/ak8975.c:431:2: error: implicit declaration of 
> function 'i2c_smbus_write_byte_data' [-Werror=implicit-function-declaration]
>   ret = i2c_smbus_write_byte_data(data->client,
>   ^
> ../drivers/iio/magnetometer/ak8975.c: In function 
> 'wait_conversion_complete_gpio':
> ../drivers/iio/magnetometer/ak8975.c:555:2: error: implicit declaration of 
> function 'i2c_smbus_read_byte_data' [-Werror=implicit-function-declaration]
>   ret = i2c_smbus_read_byte_data(client, data->def->ctrl_regs[ST1]);
>   ^
> ../drivers/iio/magnetometer/ak8975.c: In function 'ak8975_read_axis':
> ../drivers/iio/magnetometer/ak8975.c:650:2: error: implicit declaration of 
> function 'i2c_smbus_read_word_data' [-Werror=implicit-function-declaration]
>   ret = i2c_smbus_read_word_data(client, data->def->data_regs[index]);
>   ^
> ../drivers/iio/magnetometer/ak8975.c: At top level:
> ../drivers/iio/magnetometer/ak8975.c:846:1: warning: data definition has no 
> type or storage class [enabled by default]
>  module_i2c_driver(ak8975_driver);
>  ^
> ../drivers/iio/magnetometer/ak8975.c:846:1: error: type defaults to 'int' in 
> declaration of 'module_i2c_driver' [-Werror=implicit-int]
> ../drivers/iio/magnetometer/ak8975.c:846:1: warning: parameter names (without 
> types) in function declaration [enabled by default]
> ../drivers/iio/magnetometer/ak8975.c:837:26: warning: 'ak8975_driver' defined 
> but not used [-Wunused-variable]
>  static struct i2c_driver ak8975_driver = {
>   ^
> cc1: some warnings being treated as errors
> make[4]: *** [drivers/iio/magnetometer/ak8975.o] Error 1
> 
> 


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

Re: linux-next: Tree for Feb 13 (iio/magnetometer/ak8975.c)

[Randy Dunlap]

On 02/12/15 21:56, Stephen Rothwell wrote:
> Hi all,
> 
> Please do not add any material destined for v3.21 to your linux-next
> included trees until after v3.20-rc1 has been released.
> 
> Changes since 20150212:

on i386:  when CONFIG_I2C is not enabled:

../drivers/iio/magnetometer/ak8975.c: In function 'ak8975_who_i_am':
../drivers/iio/magnetometer/ak8975.c:393:2: error: implicit declaration of 
function 'i2c_smbus_read_i2c_block_data' [-Werror=implicit-function-declaration]
  ret = i2c_smbus_read_i2c_block_data(client, AK09912_REG_WIA1,
  ^
../drivers/iio/magnetometer/ak8975.c: In function 'ak8975_set_mode':
../drivers/iio/magnetometer/ak8975.c:431:2: error: implicit declaration of 
function 'i2c_smbus_write_byte_data' [-Werror=implicit-function-declaration]
  ret = i2c_smbus_write_byte_data(data->client,
  ^
../drivers/iio/magnetometer/ak8975.c: In function 
'wait_conversion_complete_gpio':
../drivers/iio/magnetometer/ak8975.c:555:2: error: implicit declaration of 
function 'i2c_smbus_read_byte_data' [-Werror=implicit-function-declaration]
  ret = i2c_smbus_read_byte_data(client, data->def->ctrl_regs[ST1]);
  ^
../drivers/iio/magnetometer/ak8975.c: In function 'ak8975_read_axis':
../drivers/iio/magnetometer/ak8975.c:650:2: error: implicit declaration of 
function 'i2c_smbus_read_word_data' [-Werror=implicit-function-declaration]
  ret = i2c_smbus_read_word_data(client, data->def->data_regs[index]);
  ^
../drivers/iio/magnetometer/ak8975.c: At top level:
../drivers/iio/magnetometer/ak8975.c:846:1: warning: data definition has no 
type or storage class [enabled by default]
 module_i2c_driver(ak8975_driver);
 ^
../drivers/iio/magnetometer/ak8975.c:846:1: error: type defaults to 'int' in 
declaration of 'module_i2c_driver' [-Werror=implicit-int]
../drivers/iio/magnetometer/ak8975.c:846:1: warning: parameter names (without 
types) in function declaration [enabled by default]
../drivers/iio/magnetometer/ak8975.c:837:26: warning: 'ak8975_driver' defined 
but not used [-Wunused-variable]
 static struct i2c_driver ak8975_driver = {
  ^
cc1: some warnings being treated as errors
make[4]: *** [drivers/iio/magnetometer/ak8975.o] Error 1


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

Re: [PATCH] x86: x86-opcode-map.txt: explain CALLW discrepancy between Intel and AMD

[Borislav Petkov]

On Fri, Feb 13, 2015 at 02:25:20PM +0100, Denys Vlasenko wrote:
> > Well, according to the SDM, Intel truncates too, see the LOOP/LOOPcc
> > Operation section:
> >
> > ...
> > IF BranchCond = 1
> > THEN
> > IF OperandSize = 32
> > THEN EIP ← EIP + SignExtend(DEST);
> > ELSE IF OperandSize = 64
> > THEN RIP ← RIP + SignExtend(DEST);
> > FI;
> > ELSE IF OperandSize = 16
> > THEN EIP ← EIP AND H;   <---
> >
> > and text talks about 0x67 but that's address size and it is used to size
> > the rCX register.
> >
> > So something must be setting the OperandSize and text doesn't mention
> > anywhere about 0x66 being ignored.
> >
> > Or have you been doing some empirical experiments? :-)
> 
> Yes, I did.
> 
> 32-bit case: Intel CPU truncates EIP to 16 bits:
> 
> $ cat t.S
> _start: .globl  _start
> 1:  .byte 0x66
> loop 1b
> 
> $ gcc -nostartfiles -nostdlib -m32 t.S
> 
> $ objdump -dr a.out
> a.out: file format elf32-i386
> Disassembly of section .text:
> 08048098 <_start>:
>  8048098:66   data16
>  8048099:e2 fdloop   8048098 <_start>
> 
> $ gdb ./a.out
> (gdb) run
> Program received signal SIGSEGV, Segmentation fault.
> 0x8098 in ?? ()
> 
> 
> Now let's try 64-bit version - compiling without -m32:
> 
> $ gcc -nostartfiles -nostdlib t.S
> $ ./a.out
> (runs without SEGV)
> 

AMD CPU always truncates:

32-bit:  a.out[13626]: segfault at 8098 ip 8098 sp ffa0ea20 
error 14 in a.out[8048000+1000]

64-bit:  a.out[13706]: segfault at d6 ip 00d6 sp 7fffec14e870 
error 14 in a.out[40+1000]


Intel CPU:

32-bit:  a.out[3478]: segfault at 8098 ip 8098 sp ff959da0 
error 14 in a.out[8048000+1000]

64-bit:

Make the loop terminate:

_start: .globl  _start
mov $1, %rcx
1:  .byte 0x66
loop 1b


a.out[3523]: segfault at 0 ip 004000de sp 731674e0 
error 6 in a.out[40+1000]

segfaults because we don't have the libc glue around it, rIP is intact.

So it looks like the SDM is wrong.

-- 
Regards/Gruss,
Boris.

ECO tip #101: Trim your mails when you reply.
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.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/3] Documentation: minor spelling and grammar fixes

[Randy Dunlap]

On 02/13/15 14:19, Chris J Arges wrote:
> Signed-off-by: Chris J Arges 
> ---
>  Documentation/vm/slub.txt | 12 ++--
>  1 file changed, 6 insertions(+), 6 deletions(-)
> 

Acked-by: Randy Dunlap 

Thanks.

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

Re: [PATCH 3/3] mm: slub: Add SLAB_DEBUG_CRASH option

[Christoph Lameter]

On Fri, 13 Feb 2015, Chris J Arges wrote:

> The diff doesn't show this clearly, but the BUG_ON was added to both
> free_debug_processing and alloc_debug_processing.

This is not good. There should be no BUG_ON. The problem report by the
allocator already includes a backtrace. You need to abort with the crash
dump. Maybe print a message describing what is going on before.

Crash dump and abort would make most sense in slab_err() and object_err().


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

ZAPYTANIE O ZGODĘ NA WYSŁANIE OFERTY / INFORMACJI HANDLOWEJ

[naukajezykow]

Szkoła Nauki Języków Obcych prosi o wyrażenie zgody na przesłanie materiałów 
reklamowo-informacyjno-handlowych w zakresie:
 


1. Realizacji szkoleń branżowych i specjalistycznych dla osób posługujących się 
językiem obcym.

2. Nauki języka ogólnego na wszystkich poziomach zaawansowania - general 
language.

3. Audytu językowego



Będziemy wdzięczni za kontakt do Osób/Osoby zainteresowanej/nych

Niniejsze zapytanie nie jest informacją handlową, a jedynie zapytaniem o
zgodę na przesyłanie informacji handlowych drogą elektroniczną, zgodnie z
art. 10 ustawy z dnia 18 lipca 2002r. o świadczeniu usług drogą
elektroniczną. (Dz.U. z 2002r. Nr 144, poz 1204 z późn. zm.)



Dziękujemy i pozdrawiamy


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

Re: [PATCH RFC v3 4/7] epoll: Add implementation for epoll_ctl_batch

[Dan Rosenberg]

> + if (ncmds <= 0 || !cmds)
> + return -EINVAL;
> + cmd_size = sizeof(struct epoll_ctl_cmd) * ncmds;
> + kcmds = kmalloc(cmd_size, GFP_KERNEL);
You should probably fix the integer overflow in the calculation of the
cmd_size variable, unless you like root vulnerabilities.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.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] ARM: smp: Only expose /sys/.../cpuX/online if hotpluggable

[Stephen Boyd]

On 02/13/15 15:01, Russell King - ARM Linux wrote:
> On Fri, Feb 13, 2015 at 09:44:50PM +, Magnus Damm wrote:
>> Also, based on the comment in mcpm_cpu_can_disable() it looks like the
>> PSCI hook may be executed once only with your change in place?
>> Hopefully PSCI is OK not being invoked for every CPU shutdown.
> This is why I've said (in the parent thread) that I'm not happy to
> apply this patch.  Mark Rutland has indicated that he has MCPM cases
> where the CPUs which can be disabled changes dynamically according
> to the secure firmware requirements, and ripping out todays
> infrastructure in light of that, only to have to add it back again
> later makes no sense.

Putting it back is not hard. And the infrastructure is not currently
used for these purposes so renaming it is appropriate. I can leave it in
place if you like, i.e. make a new op for cpu_can_disable and repoint
mcpm's mcpm_cpu_disable() at it. Then when mcpm gets migrate support it
can actually implement a cpu_disable op.

>
> However, cleaning things up by removing unnecessary cpu_disable
> methods is a good thing to do irrespective of that.
>

That's fine I can split it out.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

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

Re: [PATCH 3/3] mm: slub: Add SLAB_DEBUG_CRASH option

[Christoph Lameter]

On Fri, 13 Feb 2015, David Rientjes wrote:

> Why isn't this done in other debugging functions such as
> free_debug_processing()?

I think this belongs into the functions that report the bug. They should
report the issue and at the end of the report crash.

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

Re: [PATCH 3/3] mm: slub: Add SLAB_DEBUG_CRASH option

[Chris J Arges]

On 02/13/2015 05:38 PM, David Rientjes wrote:
> On Fri, 13 Feb 2015, Chris J Arges wrote:
> 
>> This option crashes the kernel whenever corruption is initially detected. 
>> This
>> is useful when trying to use crash dump analysis to determine where memory 
>> was
>> corrupted.
>>
>> To enable this option use slub_debug=C.
>>
> 
> Why isn't this done in other debugging functions such as 
> free_debug_processing()?
> 

The diff doesn't show this clearly, but the BUG_ON was added to both
free_debug_processing and alloc_debug_processing.

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

Re: [PATCH 3/3] mm: slub: Add SLAB_DEBUG_CRASH option

[David Rientjes]

On Fri, 13 Feb 2015, Chris J Arges wrote:

> This option crashes the kernel whenever corruption is initially detected. This
> is useful when trying to use crash dump analysis to determine where memory was
> corrupted.
> 
> To enable this option use slub_debug=C.
> 

Why isn't this done in other debugging functions such as 
free_debug_processing()?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.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: Tree for Feb 13 (runtime failures and 'non-zero nr_pmds' messages)

[Stephen Rothwell]

Hi Guenter,

On Fri, 13 Feb 2015 10:54:28 -0800 Guenter Roeck  wrote:
>
> I see a number of runtime failures with this version.
> It affects alpha, mips64, ppc64, and x86_64.
> Symptom is always the same. There are lots of
> 
> BUG: non-zero nr_pmds on freeing mm: X (where X is 1..4)
> 
> messages in the log, and the affected VMs don't reboot.
> 
> I don't see the problem in curent mainline, nor in mmotm.
> Bisect points to "Merge branch 'akpm-current/current'",
> which isn't really helpful.
> 
> Not sure if this is a bad merge resolution, so just take this
> as a heads-up for now.

Yours is the second report overnight (see attached).  Almost certainly
a bad merge resolution on my part (its a bit hard when Andrew get part
of his patch set merged by Linus :-()

I will fix up the merge on Monday (unless Andrew gets more stuff merged
or updates mmotm for me).

Sorry about that.
-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au
--- Begin Message ---
2015-02-13, 16:56:15 +1100, Stephen Rothwell wrote:
> Hi all,
> 
> Please do not add any material destined for v3.21 to your linux-next
> included trees until after v3.20-rc1 has been released.
> 
> Changes since 20150212:

Hi Stephen,

Your conflict resolution in

8fe7fba50596 "Merge branch 'akpm-current/current'"

for mm/memory.c looks a bit off.  I get flooded with these messages:

  BUG: non-zero nr_pmds on freeing mm: 4

and fixed it with:


diff --git a/mm/memory.c b/mm/memory.c
index 450e4952c5ef..802adda2b0b6 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -3350,7 +3350,6 @@ int __pmd_alloc(struct mm_struct *mm, pud_t *pud, 
unsigned long address)
smp_wmb(); /* See comment in __pte_alloc */
 
spin_lock(>page_table_lock);
-   mm_inc_nr_pmds(mm);
 #ifndef __ARCH_HAS_4LEVEL_HACK
if (!pud_present(*pud)) {
mm_inc_nr_pmds(mm);


references:
http://www.spinics.net/lists/linux-mm/msg84294.html
dc6c9a35b66b "mm: account pmd page tables to the process"

[CC'ed Kirill A. Shutemov]


Thanks

-- 
Sabrina
--- End Message ---


pgp9Hoo3gQhMf.pgp
Description: OpenPGP digital signature

Investment Opportunity

[BellAir LLC]

I bring you an investment opportunity to partner with us in this 2015
lucrative investment trading platform. Reply for more info;

Dr. Tony O'Reilly

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

Re: [PATCH 2/3] mm: slub: parse slub_debug O option in switch statement

[David Rientjes]

On Fri, 13 Feb 2015, Chris J Arges wrote:

> By moving the O option detection into the switch statement, we allow this
> parameter to be combined with other options correctly. Previously options like
> slub_debug=OFZ would only detect the 'o' and use DEBUG_DEFAULT_FLAGS to fill
> in the rest of the flags.
> 
> Signed-off-by: Chris J Arges 

Acked-by: David Rientjes 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.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] x86, kaslr: propagate base load address calculation

[Kees Cook]

On Fri, Feb 13, 2015 at 2:20 PM, Jiri Kosina  wrote:
> On Fri, 13 Feb 2015, Kees Cook wrote:
>
>> > Commit e2b32e678 ("x86, kaslr: randomize module base load address") makes
>> > the base address for module to be unconditionally randomized in case when
>> > CONFIG_RANDOMIZE_BASE is defined and "nokaslr" option isn't present on the
>> > commandline.
>> >
>> > This is not consistent with how choose_kernel_location() decides whether
>> > it will randomize kernel load base.
>> >
>> > Namely, CONFIG_HIBERNATION disables kASLR (unless "kaslr" option is
>> > explicitly specified on kernel commandline), which makes the state space
>> > larger than what module loader is looking at. IOW CONFIG_HIBERNATION &&
>> > CONFIG_RANDOMIZE_BASE is a valid config option, kASLR wouldn't be applied
>> > by default in that case, but module loader is not aware of that.
>> >
>> > Instead of fixing the logic in module.c, this patch takes more generic
>> > aproach. It introduces a new bootparam setup data_type SETUP_KASLR and
>> > uses that to pass the information whether kaslr has been applied during
>> > kernel decompression, and sets a global 'kaslr_enabled' variable
>> > accordingly, so that any kernel code (module loading, livepatching, ...)
>> > can make decisions based on its value.
>> >
>> > x86 module loader is converted to make use of this flag.
>> >
>> > Signed-off-by: Jiri Kosina 
>>
>> Thanks for working on this! If others are happy with the setup_data
>> approach, I think this is fine.
>
> This is for x86 folks to decide. I hope my original CC covers this, so
> let's wait for their verdict.
>
>> My only concern is confusion over seeing SETUP_KASLR that was added by a
>> boot loader.
>
> Well, so you are concerned about bootloader that is evil on purpose?

No, no; I agree: a malicious boot loader is a lost cause. I mean
mostly from a misbehavior perspective. Like, someone sees "kaslr" in
the setup args and thinks they can set it to 1 and boot a kernel, etc.
Or they set it to 0, but they lack HIBERNATION and "1" gets appended,
but the setup_data parser sees the boot-loader one set to 0, etc. I'm
just curious if we should avoid getting some poor system into a
confusing state.

>
> If you have such bootloader, you are screwed anyway, because it's free to
> setup asynchronous events that will corrupt your kernel anyway (DMA that
> will happen only after the loaded kernel is already active, for example).
> If you want to avoid evil bootloaders, secure boot is currently The
> option, I am afraid.
>
>> Another way to handle it might be to do some kind of relocs-like poking
>> of a value into the decompressed kernel?
>
> This is so hackish that I'd like to avoid it in favor of the boot params
> aproach as much as possbile :)

Yeah, I think so too. :)

>
> [ ... snip ... ]
>> > diff --git a/arch/x86/boot/compressed/aslr.c 
>> > b/arch/x86/boot/compressed/aslr.c
>> > index bb13763..d9d1da9 100644
>> > --- a/arch/x86/boot/compressed/aslr.c
>> > +++ b/arch/x86/boot/compressed/aslr.c
>> > @@ -14,6 +14,13 @@
>> >  static const char build_str[] = UTS_RELEASE " (" LINUX_COMPILE_BY "@"
>> > LINUX_COMPILE_HOST ") (" LINUX_COMPILER ") " UTS_VERSION;
>> >
>> > +struct kaslr_setup_data {
>>
>> Should this be "static"?
>
> Good catch. So let's wait what x86 folks have to say. I'll either update
> in in v3, or hopefully someone will fix this when applying the patch for
> -tip.

Great!

-Kees

>
> Thanks,
>
> --
> Jiri Kosina
> SUSE Labs



-- 
Kees Cook
Chrome OS Security
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.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] ARM: smp: Only expose /sys/.../cpuX/online if hotpluggable

[Simon Horman]

On Fri, Feb 13, 2015 at 10:57:04PM +, Russell King - ARM Linux wrote:
> On Fri, Feb 13, 2015 at 03:20:04PM -0500, Simon Horman wrote:
> > > -static int r8a7779_cpu_disable(unsigned int cpu)
> > > -{
> > > - /* only CPU1->3 have power domains, do not allow hotplug of CPU0 */
> > > - return cpu == 0 ? -EPERM : 0;
> > > -}
> ...
> > Its not clear to me why r8a7779_cpu_disable() has been
> > removed rather than replaced by r8a7779_cpu_can_disable()
> 
> This is the default if you don't provide a cpu_disable function, so it
> should be removed irrespective of this patch.

Thanks and agreed.

I'd be quite happy to take such a patch through my tree.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.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] tty: serial: 8250_core: read only RX if there is something in the FIFO

[Russell King - ARM Linux]

On Fri, Feb 13, 2015 at 07:51:16PM +0100, Sebastian Andrzej Siewior wrote:
> Something like this maybe?

My personal feeling is that as 0aa525d11859 was wrong, it should be
reverted and this should be another attempt to fix the problem.  In
other words, there should be two patches, one a revert of the previously
known bad commit and this one having another go at it.

I feel that would be a better approach, since then we don't end up
with this change building on a previously know buggy change.  It
would also make the changes to this solution from the previous,
known-to-work-for-decades code more obvious.

-- 
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.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/3] Documentation: minor spelling and grammar fixes

[David Rientjes]

On Fri, 13 Feb 2015, Chris J Arges wrote:

> Signed-off-by: Chris J Arges 

Acked-by: David Rientjes 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.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 01/11] ARM: vexpress: use ARM_CPU_SUSPEND if needed

[Nicolas Pitre]

On Fri, 13 Feb 2015, Liviu Dudau wrote:

> On Fri, Feb 13, 2015 at 11:16:12AM +, Russell King - ARM Linux wrote:
> > On Fri, Feb 13, 2015 at 11:01:52AM +, Liviu Dudau wrote:
> > > On Fri, Feb 13, 2015 at 10:57:53AM +, Russell King - ARM Linux wrote:
> > > > On Fri, Feb 13, 2015 at 10:37:16AM +, Liviu Dudau wrote:
> > > > > On Thu, Feb 12, 2015 at 07:42:33PM +, Arnd Bergmann wrote:
> > > > > > The vexpress tc2 power management code calls mcpm_loopback, which
> > > > > > is only available if ARM_CPU_SUSPEND is enabled, otherwise we
> > > > > > get a link error:
> > > > > > 
> > > > > > arch/arm/mach-vexpress/built-in.o: In function `tc2_pm_init':
> > > > > > arch/arm/mach-vexpress/tc2_pm.c:389: undefined reference to 
> > > > > > `mcpm_loopback'
> > > > > 
> > > > > Arnd,
> > > > > 
> > > > > We are having reports of TC2 not booting with MCPM enabled. Lorenzo
> > > > > was investigating this but then headed for Linaro Connect this week,
> > > > > so we don't have yet a resolution. Can this patch be postponed for
> > > > > a later -rc?
> > > > 
> > > > Why?
> > > > 
> > > > This patch isn't forcing MCPM to be enabled for Versatile Express.
> > > > 
> > > > * In order to build tc2_pm.c, MCPM must already be enabled (the
> > > >   feature depends on MCPM in the Kconfig already)
> > > > * When this feature is enabled, the above link error occurs if
> > > >   ARM_CPU_SUSPEND is not also enabled.
> > > > 
> > > > So, it is merely fixing the requirement that tc2_pm.c needs the CPU
> > > > suspend infrastructure, which in turn has no effect on whether MCPM
> > > > is enabled or not.
> > > 
> > > Because I think Lorenzo's plan was to disable MCPM for TC2. Which would
> > > make this patch moot.
> > 
> > I don't think that makes a difference - the two issues are orthogonal.
> > 
> > As the code stands today, it requires ARM_CPU_SUSPEND to be set, so
> > merging this change makes total sense.
> > 
> > If the code is temporarily disabled, then we still need this patch
> > merged to fix the error when the feature is re-enabled.  If the code
> > is changed later such that it doesn't need mcpm_loopback, then that's
> > the time to remove the select of this symbol.
> > 
> > If the code is removed, that is something which is not going to happen
> > during this merge window, so the patch still might as well be applied
> > to prevent build errors.
> 
> Russell,
> 
> I'm not arguing either way, I was just asking for a delay until Lorenzo
> (one other maintainer of the code that is in the Cc) has a chance to
> have his say, because I thought it was relevant (and I have explained why).
> 
> If Arnd feels he would rather push the patch now rather than (let say) late
> Monday, then I can give my Acked-by.

Sorry but I must disagree.

As the original author of that file _and_ actually being responsible for 
the bug fixed by that patch, I really don't understand why waiting for 
Lorenzo would be necessary here.


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] ARM: smp: Only expose /sys/.../cpuX/online if hotpluggable

[Russell King - ARM Linux]

On Fri, Feb 13, 2015 at 09:44:50PM +, Magnus Damm wrote:
> Also, based on the comment in mcpm_cpu_can_disable() it looks like the
> PSCI hook may be executed once only with your change in place?
> Hopefully PSCI is OK not being invoked for every CPU shutdown.

This is why I've said (in the parent thread) that I'm not happy to
apply this patch.  Mark Rutland has indicated that he has MCPM cases
where the CPUs which can be disabled changes dynamically according
to the secure firmware requirements, and ripping out todays
infrastructure in light of that, only to have to add it back again
later makes no sense.

However, cleaning things up by removing unnecessary cpu_disable
methods is a good thing to do irrespective of that.

-- 
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.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] ARM: smp: Only expose /sys/.../cpuX/online if hotpluggable

[Russell King - ARM Linux]

On Fri, Feb 13, 2015 at 08:54:22PM +, Magnus Damm wrote:
> Thanks for your efforts. Can you please tell me where that limitation
> is located? I'm quite sure I've brought CPU cores up and down
> including CPU0, but maybe something is missing?

If you don't provide a cpu_disable function, by default only the non-boot
(iow, non-CPU0) CPUs can be hotplugged.

If you provide a cpu_disable function, it can instruct the system that
fewer or more CPUs can be hotplugged, including the boot CPU.  The system
will then restrict you to a minimum of any one CPU online.

-- 
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.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] ARM: smp: Only expose /sys/.../cpuX/online if hotpluggable

[Russell King - ARM Linux]

On Fri, Feb 13, 2015 at 03:20:04PM -0500, Simon Horman wrote:
> > -static int r8a7779_cpu_disable(unsigned int cpu)
> > -{
> > -   /* only CPU1->3 have power domains, do not allow hotplug of CPU0 */
> > -   return cpu == 0 ? -EPERM : 0;
> > -}
...
> Its not clear to me why r8a7779_cpu_disable() has been
> removed rather than replaced by r8a7779_cpu_can_disable()

This is the default if you don't provide a cpu_disable function, so it
should be removed irrespective of this patch.

-- 
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.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 01/11] ARM: vexpress: use ARM_CPU_SUSPEND if needed

[Nicolas Pitre]

On Fri, 13 Feb 2015, Liviu Dudau wrote:

> On Thu, Feb 12, 2015 at 07:42:33PM +, Arnd Bergmann wrote:
> > The vexpress tc2 power management code calls mcpm_loopback, which
> > is only available if ARM_CPU_SUSPEND is enabled, otherwise we
> > get a link error:
> > 
> > arch/arm/mach-vexpress/built-in.o: In function `tc2_pm_init':
> > arch/arm/mach-vexpress/tc2_pm.c:389: undefined reference to `mcpm_loopback'
> 
> Arnd,
> 
> We are having reports of TC2 not booting with MCPM enabled. Lorenzo
> was investigating this but then headed for Linaro Connect this week,
> so we don't have yet a resolution. Can this patch be postponed for
> a later -rc?

Can you share those reports?  I did boot my TC2 with v3.19-rc7 before 
leaving for Linaro Connect and it just worked.

Regardless, this patch is about a build fix and doesn't change any 
functionality, so I wouldn't postpone it.



> 
> Best regards,
> Liviu
> 
> 
> > 
> > This explicitly selects ARM_CPU_SUSPEND like other platforms that
> > need it.
> > 
> > Signed-off-by: Arnd Bergmann 
> > Fixes: 3592d7e002438 ("ARM: 8082/1: TC2: test the MCPM loopback during 
> > boot")
> > Cc: Nicolas Pitre 
> > Cc: Kevin Hilman 
> > Cc: Liviu Dudau 
> > Cc: Sudeep Holla 
> > Cc: Lorenzo Pieralisi 
> > ---
> >  arch/arm/mach-vexpress/Kconfig | 1 +
> >  1 file changed, 1 insertion(+)
> > 
> > diff --git a/arch/arm/mach-vexpress/Kconfig b/arch/arm/mach-vexpress/Kconfig
> > index d6b16d9a7838..3c2509b4b694 100644
> > --- a/arch/arm/mach-vexpress/Kconfig
> > +++ b/arch/arm/mach-vexpress/Kconfig
> > @@ -73,6 +73,7 @@ config ARCH_VEXPRESS_TC2_PM
> > depends on MCPM
> > select ARM_CCI
> > select ARCH_VEXPRESS_SPC
> > +   select ARM_CPU_SUSPEND
> > help
> >   Support for CPU and cluster power management on Versatile Express
> >   with a TC2 (A15x2 A7x3) big.LITTLE core tile.
> > -- 
> > 2.1.0.rc2
> > 
> > 
> 
> -- 
> 
> | I would like to |
> | fix the world,  |
> | but they're not |
> | giving me the   |
>  \ source 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/
> 
> 

[PATCH] sh_vou: fix memory leak on error paths in sh_vou_open()

[Alexey Khoroshilov]

Memory allocated for sh_vou_file is not deallocated
on error paths in sh_vou_open().

Found by Linux Driver Verification project (linuxtesting.org).

Signed-off-by: Alexey Khoroshilov 
---
 drivers/media/platform/sh_vou.c | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/media/platform/sh_vou.c b/drivers/media/platform/sh_vou.c
index 261f1195b49f..6d1959d1ad02 100644
--- a/drivers/media/platform/sh_vou.c
+++ b/drivers/media/platform/sh_vou.c
@@ -1168,10 +1168,10 @@ static int sh_vou_open(struct file *file)
 
dev_dbg(vou_dev->v4l2_dev.dev, "%s()\n", __func__);
 
-   file->private_data = vou_file;
-
-   if (mutex_lock_interruptible(_dev->fop_lock))
+   if (mutex_lock_interruptible(_dev->fop_lock)) {
+   kfree(vou_file);
return -ERESTARTSYS;
+   }
if (atomic_inc_return(_dev->use_count) == 1) {
int ret;
/* First open */
@@ -1183,6 +1183,7 @@ static int sh_vou_open(struct file *file)
pm_runtime_put(vou_dev->v4l2_dev.dev);
vou_dev->status = SH_VOU_IDLE;
mutex_unlock(_dev->fop_lock);
+   kfree(vou_file);
return ret;
}
}
@@ -1195,6 +1196,8 @@ static int sh_vou_open(struct file *file)
   vou_dev->vdev, _dev->fop_lock);
mutex_unlock(_dev->fop_lock);
 
+   file->private_data = vou_file;
+
return 0;
 }
 
-- 
1.9.1

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

Re: [PATCH 3/3] x86, crash: Allocate enough low-mem when crashkernel=high

[Joerg Roedel]

Hi Baoquan,

On Fri, Feb 13, 2015 at 11:34:38PM +0800, Baoquan He wrote:
> Conclusively, I like 256M since the testing data showed it's sufficient
> now and should be save for a long time.

Thanks, I am fine with 256MB too, so can I have your Acked-by on this
series? I will rebase and resend it then after the merge window in the
hope it gets queued.


Joerg

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.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] dgnc: Use ccflags -y instead of EXTRA_CFLAGS

[Dan Carpenter]

On Fri, Feb 13, 2015 at 08:01:36PM +, Cass May wrote:
> Correction to syntax error in previous patch version. Apologies.
> 

Put that stuff under the --- cut off line and not in the permanent
kernel git log.

Changelog is missing.  checkpatch.pl by itself is not sufficient
justification.  Why did the authors of checkpatch think this way is
better?

> Signed-off-by: Cass May 
> ---
>  drivers/staging/dgnc/Makefile | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/staging/dgnc/Makefile b/drivers/staging/dgnc/Makefile
> index b69f7b6..a278900 100644
> --- a/drivers/staging/dgnc/Makefile
> +++ b/drivers/staging/dgnc/Makefile
> @@ -1,4 +1,4 @@
> -EXTRA_CFLAGS += -DDG_NAME=\"dgnc-1.3-16\" -DDG_PART=\"40002369_F\"
> +ccflags-y := -DDG_NAME=\"dgnc-1.3-16\" -DDG_PART=\"40002369_F\"

This isn't the right fix.  Is this stuff even needed?  Hopefully, not
but please check and resend a different fix.

regards,
dan carpenter

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

Re: [PATCH v2] x86, kaslr: propagate base load address calculation

[Jiri Kosina]

On Fri, 13 Feb 2015, Kees Cook wrote:

> > Commit e2b32e678 ("x86, kaslr: randomize module base load address") makes
> > the base address for module to be unconditionally randomized in case when
> > CONFIG_RANDOMIZE_BASE is defined and "nokaslr" option isn't present on the
> > commandline.
> >
> > This is not consistent with how choose_kernel_location() decides whether
> > it will randomize kernel load base.
> >
> > Namely, CONFIG_HIBERNATION disables kASLR (unless "kaslr" option is
> > explicitly specified on kernel commandline), which makes the state space
> > larger than what module loader is looking at. IOW CONFIG_HIBERNATION &&
> > CONFIG_RANDOMIZE_BASE is a valid config option, kASLR wouldn't be applied
> > by default in that case, but module loader is not aware of that.
> >
> > Instead of fixing the logic in module.c, this patch takes more generic
> > aproach. It introduces a new bootparam setup data_type SETUP_KASLR and
> > uses that to pass the information whether kaslr has been applied during
> > kernel decompression, and sets a global 'kaslr_enabled' variable
> > accordingly, so that any kernel code (module loading, livepatching, ...)
> > can make decisions based on its value.
> >
> > x86 module loader is converted to make use of this flag.
> >
> > Signed-off-by: Jiri Kosina 
> 
> Thanks for working on this! If others are happy with the setup_data
> approach, I think this is fine. 

This is for x86 folks to decide. I hope my original CC covers this, so 
let's wait for their verdict.

> My only concern is confusion over seeing SETUP_KASLR that was added by a 
> boot loader.

Well, so you are concerned about bootloader that is evil on purpose?

If you have such bootloader, you are screwed anyway, because it's free to 
setup asynchronous events that will corrupt your kernel anyway (DMA that 
will happen only after the loaded kernel is already active, for example). 
If you want to avoid evil bootloaders, secure boot is currently The 
option, I am afraid.

> Another way to handle it might be to do some kind of relocs-like poking 
> of a value into the decompressed kernel?

This is so hackish that I'd like to avoid it in favor of the boot params 
aproach as much as possbile :)

[ ... snip ... ]
> > diff --git a/arch/x86/boot/compressed/aslr.c 
> > b/arch/x86/boot/compressed/aslr.c
> > index bb13763..d9d1da9 100644
> > --- a/arch/x86/boot/compressed/aslr.c
> > +++ b/arch/x86/boot/compressed/aslr.c
> > @@ -14,6 +14,13 @@
> >  static const char build_str[] = UTS_RELEASE " (" LINUX_COMPILE_BY "@"
> > LINUX_COMPILE_HOST ") (" LINUX_COMPILER ") " UTS_VERSION;
> >
> > +struct kaslr_setup_data {
> 
> Should this be "static"?

Good catch. So let's wait what x86 folks have to say. I'll either update 
in in v3, or hopefully someone will fix this when applying the patch for 
-tip.

Thanks,

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

[PATCH 3/3] mm: slub: Add SLAB_DEBUG_CRASH option

[Chris J Arges]

This option crashes the kernel whenever corruption is initially detected. This
is useful when trying to use crash dump analysis to determine where memory was
corrupted.

To enable this option use slub_debug=C.

Signed-off-by: Chris J Arges 
---
 Documentation/vm/slub.txt |  2 ++
 include/linux/slab.h  |  1 +
 mm/slub.c | 10 ++
 3 files changed, 13 insertions(+)

diff --git a/Documentation/vm/slub.txt b/Documentation/vm/slub.txt
index e159c04..78fbe44 100644
--- a/Documentation/vm/slub.txt
+++ b/Documentation/vm/slub.txt
@@ -44,6 +44,8 @@ Possible debug options are
A   Toggle failslab filter mark for the cache
O   Switch debugging off for caches that would have
caused higher minimum slab orders
+   C   Crash kernel on corruption detection. (Useful for
+   debugging with crash dumps)
-   Switch all debugging off (useful if the kernel is
configured with CONFIG_SLUB_DEBUG_ON)
 
diff --git a/include/linux/slab.h b/include/linux/slab.h
index ed2ffaa..6c8eda9 100644
--- a/include/linux/slab.h
+++ b/include/linux/slab.h
@@ -23,6 +23,7 @@
 #define SLAB_DEBUG_FREE0x0100UL/* DEBUG: Perform 
(expensive) checks on free */
 #define SLAB_RED_ZONE  0x0400UL/* DEBUG: Red zone objs in a 
cache */
 #define SLAB_POISON0x0800UL/* DEBUG: Poison objects */
+#define SLAB_DEBUG_CRASH   0x1000UL/* DEBUG: Crash on any errors 
detected */
 #define SLAB_HWCACHE_ALIGN 0x2000UL/* Align objs on cache lines */
 #define SLAB_CACHE_DMA 0x4000UL/* Use GFP_DMA memory */
 #define SLAB_STORE_USER0x0001UL/* DEBUG: Store the 
last owner for bug hunting */
diff --git a/mm/slub.c b/mm/slub.c
index 88482f8..1eb0031 100644
--- a/mm/slub.c
+++ b/mm/slub.c
@@ -1025,6 +1025,9 @@ static noinline int alloc_debug_processing(struct 
kmem_cache *s,
return 1;
 
 bad:
+   /* BUG_ON to trace initial corruption */
+   BUG_ON(s->flags & SLAB_DEBUG_CRASH);
+
if (PageSlab(page)) {
/*
 * If this is a slab page then lets do the best we can
@@ -1092,6 +1095,10 @@ out:
 fail:
slab_unlock(page);
spin_unlock_irqrestore(>list_lock, *flags);
+
+   /* BUG_ON to trace initial corruption */
+   BUG_ON(s->flags & SLAB_DEBUG_CRASH);
+
slab_fix(s, "Object at 0x%p not freed", object);
return NULL;
 }
@@ -1149,6 +1156,9 @@ static int __init setup_slub_debug(char *str)
 */
disable_higher_order_debug = 1;
break;
+   case 'c':
+   slub_debug |= SLAB_DEBUG_CRASH;
+   break;
default:
pr_err("slub_debug option '%c' unknown. skipped\n",
   *str);
-- 
1.9.1

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

[PATCH 2/3] mm: slub: parse slub_debug O option in switch statement

[Chris J Arges]

By moving the O option detection into the switch statement, we allow this
parameter to be combined with other options correctly. Previously options like
slub_debug=OFZ would only detect the 'o' and use DEBUG_DEFAULT_FLAGS to fill
in the rest of the flags.

Signed-off-by: Chris J Arges 
---
 mm/slub.c | 16 +++-
 1 file changed, 7 insertions(+), 9 deletions(-)

diff --git a/mm/slub.c b/mm/slub.c
index 06cdb18..88482f8 100644
--- a/mm/slub.c
+++ b/mm/slub.c
@@ -1112,15 +1112,6 @@ static int __init setup_slub_debug(char *str)
 */
goto check_slabs;
 
-   if (tolower(*str) == 'o') {
-   /*
-* Avoid enabling debugging on caches if its minimum order
-* would increase as a result.
-*/
-   disable_higher_order_debug = 1;
-   goto out;
-   }
-
slub_debug = 0;
if (*str == '-')
/*
@@ -1151,6 +1142,13 @@ static int __init setup_slub_debug(char *str)
case 'a':
slub_debug |= SLAB_FAILSLAB;
break;
+   case 'o':
+   /*
+* Avoid enabling debugging on caches if its minimum
+* order would increase as a result.
+*/
+   disable_higher_order_debug = 1;
+   break;
default:
pr_err("slub_debug option '%c' unknown. skipped\n",
   *str);
-- 
1.9.1

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

[PATCH 1/3] Documentation: minor spelling and grammar fixes

[Chris J Arges]

Signed-off-by: Chris J Arges 
---
 Documentation/vm/slub.txt | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/Documentation/vm/slub.txt b/Documentation/vm/slub.txt
index b0c6d1b..e159c04 100644
--- a/Documentation/vm/slub.txt
+++ b/Documentation/vm/slub.txt
@@ -64,7 +64,7 @@ to the dentry cache with
 
 Debugging options may require the minimum possible slab order to increase as
 a result of storing the metadata (for example, caches with PAGE_SIZE object
-sizes).  This has a higher liklihood of resulting in slab allocation errors
+sizes).  This has a higher likelihood of resulting in slab allocation errors
 in low memory situations or if there's high fragmentation of memory.  To
 switch off debugging for such caches by default, use
 
@@ -95,7 +95,7 @@ slabinfo -a displays which slabs were merged together.
 Slab validation
 ---
 
-SLUB can validate all object if the kernel was booted with slub_debug. In
+SLUB can validate all objects if the kernel was booted with slub_debug. In
 order to do so you must have the slabinfo tool. Then you can do
 
 slabinfo -v
@@ -125,7 +125,7 @@ In general slub will be able to perform this number of 
allocations
 on a slab without consulting centralized resources (list_lock) where
 contention may occur.
 
-slub_min_order specifies a minim order of slabs. A similar effect like
+slub_min_order specifies a minimum order of slabs. A similar effect like
 slub_min_objects.
 
 slub_max_order specified the order at which slub_min_objects should no
@@ -133,7 +133,7 @@ longer be checked. This is useful to avoid SLUB trying to 
generate
 super large order pages to fit slub_min_objects of a slab cache with
 large object sizes into one high order page. Setting command line
 parameter debug_guardpage_minorder=N (N > 0), forces setting
-slub_max_order to 0, what cause minimum possible order of slabs
+slub_max_order to 0, which causes the minimum possible order of slab
 allocation.
 
 SLUB Debug output
@@ -234,7 +234,7 @@ Padding  : 
 3. A stackdump
 
 The stackdump describes the location where the error was detected. The cause
-of the corruption is may be more likely found by looking at the function that
+of the corruption may be more likely found by looking at the function that
 allocated or freed the object.
 
 4. Report on how the problem was dealt with in order to ensure the continued
@@ -246,7 +246,7 @@ FIX : 
 
 In the above sample SLUB found that the Redzone of an active object has
 been overwritten. Here a string of 8 characters was written into a slab that
-has the length of 8 characters. However, a 8 character string needs a
+has the length of 8 characters. However, an 8 character string needs a
 terminating 0. That zero has overwritten the first byte of the Redzone field.
 After reporting the details of the issue encountered the FIX SLUB message
 tells us that SLUB has restored the Redzone to its proper value and then
-- 
1.9.1

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

Re: [PATCH] mfd: devicetree: bindings: Add Qualcomm RPM regulator subnodes

[Andy Gross]

On Thu, Jan 29, 2015 at 05:51:06PM -0800, Bjorn Andersson wrote:
> Add the regulator subnodes to the Qualcomm RPM MFD device tree bindings.
> 
> Signed-off-by: Bjorn Andersson 
> ---

>   #include 
> @@ -66,5 +237,18 @@ frequencies.
>  
>   #address-cells = <1>;
>   #size-cells = <0>;
> +
> + pm8921_smps1: pm8921-smps1 {
> + compatible = "qcom,rpm-pm8921-smps";
> + reg = ;
> +
> + regulator-min-microvolt = <1225000>;
> + regulator-max-microvolt = <1225000>;
> + regulator-always-on;
> +
> + bias-pull-down;
> +
> + qcom,switch-mode-frequency = <320>;
> + };
>   };

My only comment here is that most (all but one) of the other mfd regulator
devices use regulators {}.  Still wonder if that's what we should do.

Otherwise,

Reviewed-by: Andy Gross 


-- 
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

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

Re: [PATCH 8/8] phy: add driver for TI TUSB1210 ULPI PHY

[David Cohen]

On Fri, Feb 13, 2015 at 04:03:57PM -0600, Felipe Balbi wrote:
> On Fri, Feb 13, 2015 at 02:02:11PM -0800, David Cohen wrote:
> > Hi Felipe,
> > 
> > [snip]
> > 
> > > diff --git a/drivers/usb/dwc3/dwc3-pci.c b/drivers/usb/dwc3/dwc3-pci.c
> > > index 8d95056..53902ea 100644
> > > --- a/drivers/usb/dwc3/dwc3-pci.c
> > > +++ b/drivers/usb/dwc3/dwc3-pci.c
> > > @@ -21,6 +21,7 @@
> > >  #include 
> > >  #include 
> > >  #include 
> > > +#include 
> > >  
> > >  #include "platform_data.h"
> > >  
> > > @@ -35,6 +36,24 @@
> > >  
> > >  static int dwc3_pci_quirks(struct pci_dev *pdev)
> > >  {
> > > + if (pdev->vendor == PCI_VENDOR_ID_INTEL &&
> > > + pdev->device == PCI_DEVICE_ID_INTEL_BYT) {
> > > + struct gpio_desc *gpio;
> > > +
> > > + gpio = gpiod_get_index(>dev, "reset", 0);
> > > + if (!IS_ERR(gpio)) {
> > > + gpiod_direction_output(gpio, 0);
> > > + gpiod_set_value_cansleep(gpio, 1);
> > > + gpiod_put(gpio);
> > > + }
> > > + gpio = gpiod_get_index(>dev, "cs", 1);
> > > + if (!IS_ERR(gpio)) {
> > > + gpiod_direction_output(gpio, 0);
> > > + gpiod_set_value_cansleep(gpio, 1);
> > > + gpiod_put(gpio);
> > > + }
> > > + }
> > > +
> > 
> > A lot has been discussed in other branches of this thread.
> > 
> > But in resume, this is the last open point to make Heikki's proposal
> > good on my side. If you accept this ugly quirk (but necessary for
> > current BYT-CR products when ULPI bus enumerates phy), everything seems
> > good to me. If you don't accept, we need to figure out a way to get the
> > platform driver code back to give gpio to phy as platform data in a way
> > that it could live together with ULPI bus (BYT-CR needs the ULPI bus too).
> 
> Is this needed to *all* Baytrail devices or could we have devices with
> updated firmware which won't need this ? I wonder if we should apply the
> quirk for each known product that actually needs this.

The products that need this quirk will have the gpios on DSDT, otherwise
it won't be there. Except for the order of gpios (CS needs to be enabled
first and it's index 0 AFAIR), the quirk should follow Heikki's logic
here: if gpio isn't found we silently ignore it.

> 
> Also, I will only accept the series, after I'm shown logs that it works
> with your known-to-be-broken device.

I can provide that when Heikki resends his patch set.

Br, David

> 
> cheers
> 
> -- 
> balbi


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.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] [SCSI] bsg: fix unkillable I/O wait deadlock with scsi-mq

[Tony Battersby]

On 02/11/2015 11:31 AM, Tony Battersby wrote:
> Note: I did a number of tests with this patch, but I do not have any
> programs to test commands with bidirectional data transfer.  I would
> appreciate if someone could test that.

Replying to myself, I was able to test bidirectional data transfer using
scsi_debug and sg_raw, and it worked just fine.

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

Re: [PATCH 1/1] Staging: gdm724x: code style improvements

[Tolga Ceylan]

On Fri, Feb 13, 2015 at 1:05 AM, Dan Carpenter  wrote:
>
> You're doing too many things at one.  This should probably be split into
> 7 patches.

I will split this up and resubmit.

>
>
>>  u16 gdm_cpu_to_dev16(struct gdm_endian *ed, u16 x)
>> @@ -39,7 +38,7 @@ u16 gdm_cpu_to_dev16(struct gdm_endian *ed, u16 x)
>>   if (ed->dev_ed == ed->host_ed)
>>   return x;
>>
>> - return Endian16_Swap(x);
>> + return ENDIAN16_SWAP(x);
>>  }
>
> All the changes are good except these.  We have standard macros
> cpu_to_be16()/le16() and back for these.
>
> regards,
> dan carpenter

Thanks, I'll skip this one.

Regards,
Tolga Ceylan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.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/8] usb: dwc3: add ULPI interface support

[Felipe Balbi]

On Fri, Feb 13, 2015 at 02:03:45PM -0800, David Cohen wrote:
> Hi Heikki,
> 
> On Fri, Feb 13, 2015 at 03:16:40PM +0200, Heikki Krogerus wrote:
> > On Thu, Feb 12, 2015 at 05:41:30PM -0800, David Cohen wrote:
> > > On Thu, Feb 12, 2015 at 02:12:14PM +0200, Heikki Krogerus wrote:
> > > > > > diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
> > > > > > index a8c9062..66cbf38 100644
> > > > > > --- a/drivers/usb/dwc3/core.c
> > > > > > +++ b/drivers/usb/dwc3/core.c
> > > > > > @@ -879,6 +879,10 @@ static int dwc3_probe(struct platform_device 
> > > > > > *pdev)
> > > > > > platform_set_drvdata(pdev, dwc);
> > > > > > dwc3_cache_hwparams(dwc);
> > > > > >  
> > > > > > +   ret = dwc3_ulpi_init(dwc);
> > > > > 
> > > > > If I understood correctly, this call will result in enumerating the 
> > > > > phy
> > > > > via ULPI bus, then registering the correct ULPI device.
> > > > > Can you guarantee ULPI will be always accessible at this point if we
> > > > > remove dwc3 module and load it again?
> > > > 
> > > > OK, got it. So yes, I can guarantee that ULPI will be acessible at
> > > > this point. If we are in a state where we could soft reset dwc3, we
> > > > know we can access ULPI. The fact that dwc3 itself expects to be able
> > > > to write to the ULPI registers at that point guarantees it for us.
> > > 
> > > I just double checked DWC3 TRM.
> > > You are correct, by the time we're executing dwc3_core_soft_reset() ULPI
> > > bus is already accessible. But the TRM also specifies an ULPI phy would
> > > be reset by DCTL's core soft reset, which is executed by dwc3_core_init()
> > > before calling dwc3_core_soft_reset(). It does mention DWC3 writes data
> > > to an ULPI phy register during reset, but it also mentions the clock
> > > sync happens during that time.
> > > 
> > > That makes no even OK, but more correct IMO to power on phy before
> > > core's soft reset (i.e. by ACPI methods). But it lets us in a grey area
> > > whether ULPI is reliably accessible before core's soft reset.
> > > 
> > > I believe if you move the dwc3_ulpi_init() to dwc3_core_init(), after
> > > core's soft reset we've got no more grey area.
> > 
> > Well, we have already requested the phys in dwc3_probe before that so
> > some refactoring will be needed. It's probable no a problem.
> 
> Sounds good :)
> 
> > 
> > Btw, I'm sorry about telling this so late, but I'm going to be on
> > vacation for the next two weeks.
> 
> Thanks for the notice.

you'll be back right around merge window closing time :-) Not to worry,
we'll have time to get this into the next merge window.

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH 8/8] phy: add driver for TI TUSB1210 ULPI PHY

[Felipe Balbi]

On Fri, Feb 13, 2015 at 02:02:11PM -0800, David Cohen wrote:
> Hi Felipe,
> 
> [snip]
> 
> > diff --git a/drivers/usb/dwc3/dwc3-pci.c b/drivers/usb/dwc3/dwc3-pci.c
> > index 8d95056..53902ea 100644
> > --- a/drivers/usb/dwc3/dwc3-pci.c
> > +++ b/drivers/usb/dwc3/dwc3-pci.c
> > @@ -21,6 +21,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  
> >  #include "platform_data.h"
> >  
> > @@ -35,6 +36,24 @@
> >  
> >  static int dwc3_pci_quirks(struct pci_dev *pdev)
> >  {
> > +   if (pdev->vendor == PCI_VENDOR_ID_INTEL &&
> > +   pdev->device == PCI_DEVICE_ID_INTEL_BYT) {
> > +   struct gpio_desc *gpio;
> > +
> > +   gpio = gpiod_get_index(>dev, "reset", 0);
> > +   if (!IS_ERR(gpio)) {
> > +   gpiod_direction_output(gpio, 0);
> > +   gpiod_set_value_cansleep(gpio, 1);
> > +   gpiod_put(gpio);
> > +   }
> > +   gpio = gpiod_get_index(>dev, "cs", 1);
> > +   if (!IS_ERR(gpio)) {
> > +   gpiod_direction_output(gpio, 0);
> > +   gpiod_set_value_cansleep(gpio, 1);
> > +   gpiod_put(gpio);
> > +   }
> > +   }
> > +
> 
> A lot has been discussed in other branches of this thread.
> 
> But in resume, this is the last open point to make Heikki's proposal
> good on my side. If you accept this ugly quirk (but necessary for
> current BYT-CR products when ULPI bus enumerates phy), everything seems
> good to me. If you don't accept, we need to figure out a way to get the
> platform driver code back to give gpio to phy as platform data in a way
> that it could live together with ULPI bus (BYT-CR needs the ULPI bus too).

Is this needed to *all* Baytrail devices or could we have devices with
updated firmware which won't need this ? I wonder if we should apply the
quirk for each known product that actually needs this.

Also, I will only accept the series, after I'm shown logs that it works
with your known-to-be-broken device.

cheers

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH 1/1] Staging: iio: meter: ade7854-i2c: code style improvements

[Tolga Ceylan]

On Fri, Feb 13, 2015 at 12:27 AM, Sudip Mukherjee
 wrote:
>
> you are doing three different types of changes here. one patch should have 
> only one type of change.
>
> regards
> sudip

Thank you, I'll split this up and resubmit.

Regards,
Tolga
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.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/8] usb: dwc3: add ULPI interface support

[David Cohen]

Hi Heikki,

On Fri, Feb 13, 2015 at 03:16:40PM +0200, Heikki Krogerus wrote:
> On Thu, Feb 12, 2015 at 05:41:30PM -0800, David Cohen wrote:
> > On Thu, Feb 12, 2015 at 02:12:14PM +0200, Heikki Krogerus wrote:
> > > > > diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
> > > > > index a8c9062..66cbf38 100644
> > > > > --- a/drivers/usb/dwc3/core.c
> > > > > +++ b/drivers/usb/dwc3/core.c
> > > > > @@ -879,6 +879,10 @@ static int dwc3_probe(struct platform_device 
> > > > > *pdev)
> > > > >   platform_set_drvdata(pdev, dwc);
> > > > >   dwc3_cache_hwparams(dwc);
> > > > >  
> > > > > + ret = dwc3_ulpi_init(dwc);
> > > > 
> > > > If I understood correctly, this call will result in enumerating the phy
> > > > via ULPI bus, then registering the correct ULPI device.
> > > > Can you guarantee ULPI will be always accessible at this point if we
> > > > remove dwc3 module and load it again?
> > > 
> > > OK, got it. So yes, I can guarantee that ULPI will be acessible at
> > > this point. If we are in a state where we could soft reset dwc3, we
> > > know we can access ULPI. The fact that dwc3 itself expects to be able
> > > to write to the ULPI registers at that point guarantees it for us.
> > 
> > I just double checked DWC3 TRM.
> > You are correct, by the time we're executing dwc3_core_soft_reset() ULPI
> > bus is already accessible. But the TRM also specifies an ULPI phy would
> > be reset by DCTL's core soft reset, which is executed by dwc3_core_init()
> > before calling dwc3_core_soft_reset(). It does mention DWC3 writes data
> > to an ULPI phy register during reset, but it also mentions the clock
> > sync happens during that time.
> > 
> > That makes no even OK, but more correct IMO to power on phy before
> > core's soft reset (i.e. by ACPI methods). But it lets us in a grey area
> > whether ULPI is reliably accessible before core's soft reset.
> > 
> > I believe if you move the dwc3_ulpi_init() to dwc3_core_init(), after
> > core's soft reset we've got no more grey area.
> 
> Well, we have already requested the phys in dwc3_probe before that so
> some refactoring will be needed. It's probable no a problem.

Sounds good :)

> 
> Btw, I'm sorry about telling this so late, but I'm going to be on
> vacation for the next two weeks.

Thanks for the notice.

Br, David

> 
> 
> Cheers,
> 
> -- 
> heikki
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.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] sched/completion: completion_done() should serialize with complete()

[Davidlohr Bueso]

On Fri, 2015-02-13 at 13:56 -0800, Davidlohr Bueso wrote:
> On Thu, 2015-02-12 at 20:59 +0100, Oleg Nesterov wrote:
> > Commit de30ec47302c "Remove unnecessary ->wait.lock serialization when
> > reading completion state" was not correct, without lock/unlock the code
> > like stop_machine_from_inactive_cpu()
> > 
> > while (!completion_done())
> > cpu_relax();
> > 
> > can return before complete() finishes its spin_unlock() which writes to
> > this memory. And spin_unlock_wait().
> 
> How about reverting the patch altogether?
> 
> This was never a problem nor have I ever seen a performance issues in
> completions that would merit these lockless checks. The commit changelog
> has *zero* information, so I don't know if this was ever a real issue.
> 

hmm I guess you're patch is more optimal tho, because we don't update
the lock, less cacheline bouncing issues etc.

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

Re: [PATCH 8/8] phy: add driver for TI TUSB1210 ULPI PHY

[David Cohen]

Hi Felipe,

[snip]

> diff --git a/drivers/usb/dwc3/dwc3-pci.c b/drivers/usb/dwc3/dwc3-pci.c
> index 8d95056..53902ea 100644
> --- a/drivers/usb/dwc3/dwc3-pci.c
> +++ b/drivers/usb/dwc3/dwc3-pci.c
> @@ -21,6 +21,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include "platform_data.h"
>  
> @@ -35,6 +36,24 @@
>  
>  static int dwc3_pci_quirks(struct pci_dev *pdev)
>  {
> + if (pdev->vendor == PCI_VENDOR_ID_INTEL &&
> + pdev->device == PCI_DEVICE_ID_INTEL_BYT) {
> + struct gpio_desc *gpio;
> +
> + gpio = gpiod_get_index(>dev, "reset", 0);
> + if (!IS_ERR(gpio)) {
> + gpiod_direction_output(gpio, 0);
> + gpiod_set_value_cansleep(gpio, 1);
> + gpiod_put(gpio);
> + }
> + gpio = gpiod_get_index(>dev, "cs", 1);
> + if (!IS_ERR(gpio)) {
> + gpiod_direction_output(gpio, 0);
> + gpiod_set_value_cansleep(gpio, 1);
> + gpiod_put(gpio);
> + }
> + }
> +

A lot has been discussed in other branches of this thread.

But in resume, this is the last open point to make Heikki's proposal
good on my side. If you accept this ugly quirk (but necessary for
current BYT-CR products when ULPI bus enumerates phy), everything seems
good to me. If you don't accept, we need to figure out a way to get the
platform driver code back to give gpio to phy as platform data in a way
that it could live together with ULPI bus (BYT-CR needs the ULPI bus too).

Br, David

>   if (pdev->vendor == PCI_VENDOR_ID_AMD &&
>   pdev->device == PCI_DEVICE_ID_AMD_NL_USB) {
>   struct dwc3_platform_data pdata;

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.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] compat: Fix endian issue in union sigval

[Chris Metcalf]

On 2/13/2015 5:44 AM, Catalin Marinas wrote:

On Fri, Feb 13, 2015 at 04:00:43PM +0800, Bamvor Jian Zhang wrote:

On 2015/2/11 23:40, Catalin Marinas wrote:

On Wed, Feb 11, 2015 at 07:22:08PM +0800, Bamvor Jian Zhang wrote:

On 2015/2/10 20:27, Catalin Marinas wrote:

On Tue, Feb 10, 2015 at 10:10:11AM +, Zhang Jian(Bamvor) wrote:

...

The native sigval_t is also a union but on 64-bit big endian, the
sival_int overlaps with the most significant 32-bit of the sival_ptr.
So reading sival_int would always be 0. When the compat siginfo is
copied to user, arm64 reads the native sival_ptr (si_ptr) and converts
it to the compat one, getting the correct 32-bit value. However, other
architectures access sival_int (si_int) instead which breaks with your
get_compat_sigevent() changes.



tile, s390:  arch/xxx/kernel/compat_signal.c


tile seems to be bi-endian, though I couldn't see a Kconfig option, nor
something defining __BIG_ENDIAN__ in headers or Makefile. I guess it's
coming from the compiler directly.


Yes, we just pick up the compiler's __BIG_ENDIAN__ if specified.


Anyway, on big endian tile, I we have
the same issue as on big endian arm64.

I think it's only tile that needs fixing for big endian, something like
the arm64 patch below:


diff --git a/arch/arm64/kernel/signal32.c b/arch/arm64/kernel/signal32.c
index e299de396e9b..32601939a3c8 100644
--- a/arch/arm64/kernel/signal32.c
+++ b/arch/arm64/kernel/signal32.c
@@ -154,8 +154,7 @@ int copy_siginfo_to_user32(compat_siginfo_t __user *to, 
const siginfo_t *from)
case __SI_TIMER:
 err |= __put_user(from->si_tid, >si_tid);
 err |= __put_user(from->si_overrun, >si_overrun);
-err |= __put_user((compat_uptr_t)(unsigned long)from->si_ptr,
-  >si_ptr);
+err |= __put_user(from->si_int, >si_int);
break;
case __SI_POLL:
err |= __put_user(from->si_band, >si_band);
@@ -184,7 +183,7 @@ int copy_siginfo_to_user32(compat_siginfo_t __user *to, 
const siginfo_t *from)
case __SI_MESGQ: /* But this is */
err |= __put_user(from->si_pid, >si_pid);
err |= __put_user(from->si_uid, >si_uid);
-   err |= __put_user((compat_uptr_t)(unsigned long)from->si_ptr, 
>si_ptr);
+   err |= __put_user(from->si_int, >si_int);
break;
case __SI_SYS:
err |= __put_user((compat_uptr_t)(unsigned long)


I must be confused here, but I don't see that these do anything different.

If we are writing 32 bits to to->si_ptr or to->si_int, either way the high 32 
bits
are irrelevant.  So whether we read it from from->si_ptr and massage the high 
bits,
or just read it from from->si_int as a straight-up 32-bit quantity, either way 
it
seems we should end up writing the same bits to userspace.

I would understand the argument if we were overlaying the si_ptr/si_int union
from a kernel-side siginfo_t where si_ptr and si_int are different sizes
onto userspace, but it doesn't seem we ever do that.

All that said, it certainly seems like the si_int version is simpler, so I 
don't have
a problem with switching to it, but I don't see how it fixes a problem.

--
Chris Metcalf, EZChip Semiconductor
http://www.ezchip.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] sched/completion: completion_done() should serialize with complete()

[Davidlohr Bueso]

On Thu, 2015-02-12 at 20:59 +0100, Oleg Nesterov wrote:
> Commit de30ec47302c "Remove unnecessary ->wait.lock serialization when
> reading completion state" was not correct, without lock/unlock the code
> like stop_machine_from_inactive_cpu()
> 
>   while (!completion_done())
>   cpu_relax();
> 
> can return before complete() finishes its spin_unlock() which writes to
> this memory. And spin_unlock_wait().

How about reverting the patch altogether?

This was never a problem nor have I ever seen a performance issues in
completions that would merit these lockless checks. The commit changelog
has *zero* information, so I don't know if this was ever a real issue.

Thanks,
Davidlohr

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

Re: [PATCH v2] ARM: smp: Only expose /sys/.../cpuX/online if hotpluggable

[Magnus Damm]

Hi Stephen,

On Fri, Feb 13, 2015 at 8:59 PM, Stephen Boyd  wrote:
> On 02/13/15 12:54, Magnus Damm wrote:
>> Hi Stephen,
>>
>> On Fri, Feb 13, 2015 at 8:23 PM, Stephen Boyd  wrote:
>>> On 02/13/15 12:20, Simon Horman wrote:
 Hi Stephen,

 On Fri, Feb 13, 2015 at 10:06:39AM -0800, Stephen Boyd wrote:
> diff --git a/arch/arm/mach-shmobile/smp-r8a7779.c 
> b/arch/arm/mach-shmobile/smp-r8a7779.c
> index 3f761f839043..b45206f93ddf 100644
> --- a/arch/arm/mach-shmobile/smp-r8a7779.c
> +++ b/arch/arm/mach-shmobile/smp-r8a7779.c
> @@ -124,19 +124,12 @@ static int r8a7779_cpu_kill(unsigned int cpu)
>
>  return 0;
>  }
> -
> -static int r8a7779_cpu_disable(unsigned int cpu)
> -{
> -/* only CPU1->3 have power domains, do not allow hotplug of CPU0 */
> -return cpu == 0 ? -EPERM : 0;
> -}
>  #endif /* CONFIG_HOTPLUG_CPU */
>
>  struct smp_operations r8a7779_smp_ops  __initdata = {
>  .smp_prepare_cpus   = r8a7779_smp_prepare_cpus,
>  .smp_boot_secondary = r8a7779_boot_secondary,
>  #ifdef CONFIG_HOTPLUG_CPU
> -.cpu_disable= r8a7779_cpu_disable,
>  .cpu_die= shmobile_smp_scu_cpu_die,
>  .cpu_kill   = r8a7779_cpu_kill,
>  #endif
 Its not clear to me why r8a7779_cpu_disable() has been
 removed rather than replaced by r8a7779_cpu_can_disable()
>>> By default ARM's smp.c assumes that CPU0 can't be hotplugged. The
>>> function is redundant. I guess I should have mentioned that in the
>>> commit text.
>> Thanks for your efforts. Can you please tell me where that limitation
>> is located? I'm quite sure I've brought CPU cores up and down
>> including CPU0, but maybe something is missing?
>>
>>
>
> The assumption is made if there isn't a cpu_disable (now
> cpu_can_disable) op. See platform_cpu_disable() in
> arch/arm/kernel/smp.c. If there isn't such a limitation on a particular
> platform, the platform needs to set the cpu_disable/cpu_can_disable op
> and indicate that there isn't a limitation (by returning 1 for example).

Thanks, I now understand.

The mach-shmobile bits look fine to me, but if I could pick freely
then I would prefer the changes to be broken out a bit more. For
instance, separate the r8a7779_cpu_disable() removal from the callback
renaming and the logic changes.

Also, based on the comment in mcpm_cpu_can_disable() it looks like the
PSCI hook may be executed once only with your change in place?
Hopefully PSCI is OK not being invoked for every CPU shutdown.

Cheers,

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

Re: [PATCH RT v2] kernel/res_counter.c: Change lock of struct res_counter to raw_spinlock_t

[Paul Gortmaker]

[Re: [PATCH RT v2] kernel/res_counter.c: Change lock of struct res_counter to 
raw_spinlock_t] On 13/02/2015 (Fri 14:21) Thavatchai Makphaibulchoke wrote:

> 
> 
> On 02/13/2015 12:19 PM, Paul Gortmaker wrote:
> > 
> > I think there is more to this issue than just a lock conversion.
> > Firstly, if we look at the existing -rt patches, we've got the old
> > patch from ~2009 that is:
> > 
> 
> Thanks Paul for testing and reporting the problem.
> 
> Yes, looks like the issue probably involve more than converting to a
> raw_spinlock_t.
> 
> >  From: Ingo Molnar 
> >  Date: Fri, 3 Jul 2009 08:44:33 -0500
> >  Subject: [PATCH] core: Do not disable interrupts on RT in res_counter.c
> > 
> > which changed the local_irq_save to local_irq_save_nort in order to
> > avoid such a raw lock conversion.
> > 
> 
> The patch did not quite state explicitly that the fix was to avoid raw
> lock conversion.  I guess one could infer so.

Yes, it is kind of the implicit choice ; don't disable interrupts, or
don't use a sleeping lock.

> 
> Anyway as the patch also mentioned, the code needs a second look.
> 
> I'll try to see if I could rework my patch.
> 
> > Also, when I test this patch on a larger machine with lots of cores, I
> > get boot up issues (general protection fault while trying to access the
> > raw lock) or RCU stalls that trigger broadcast NMI backtraces; both which
> > implicate the same code area, and they go away with a revert.
> > 
> 
> Could you please let me know how many cores/threads you are running.

Interestingly, when I did a quick sanity test on a core2-duo (~5year old
desktop) it seemed fine.  Only on the larger machine did it really go
pear shaped.  That machine looks like this:

root@yow-intel-canoe-pass-4-21774:~# cat /proc/cpuinfo |grep name|uniq
model name  : Intel(R) Xeon(R) CPU E5-2680 v2 @ 2.80GHz
root@yow-intel-canoe-pass-4-21774:~# cat /proc/cpuinfo |grep name|wc -l
20
root@yow-intel-canoe-pass-4-21774:~#

> 
> Could you please also send me a stack trace for the protection fault
> problem, if available.

I rebooted several times and the rcu fail seemed to be the most common
fail.  The machine was writing logs to /var/volatile so I don't have
a saved copy of that one :(  -- if time permits I'll have a go at
rebooting a few more times with the patch to see if I can capture it.

Paul.
--

> 
> Thanks again for reporting the problem.
> 
> Thanks,
> Mak.
> 
> 
> > Stuff like the below. Figured I'd better mention it since Steve was
> > talking about rounding up patches for stable, and the solution to the
> > original problem reported here seems to need to be revisited.
> > 
> > Paul.
> > --
> > 
> > 
> > [   38.615736] NMI backtrace for cpu 15
> > [   38.615739] CPU: 15 PID: 835 Comm: ovirt-engine.py Not tainted 
> > 3.14.33-rt28-WR7.0.0.0_ovp+ #3
> > [   38.615740] Hardware name: Intel Corporation S2600CP/S2600CP, BIOS 
> > SE5C600.86B.02.01.0002.082220131453 08/22/2013
> > [   38.615742] task: 880faca8 ti: 880f9d89 task.ti: 
> > 880f9d89
> > [   38.615751] RIP: 0010:[]  [] 
> > preempt_count_add+0x41/0xb0
> > [   38.615752] RSP: 0018:880ffd5e3d00  EFLAGS: 0097
> > [   38.615754] RAX: 00010002 RBX: 0001 RCX: 
> > 
> > [   38.615755] RDX:  RSI: 0100 RDI: 
> > 0001
> > [   38.615756] RBP: 880ffd5e3d08 R08: 82317700 R09: 
> > 0028
> > [   38.615757] R10: 000f R11: 00017484 R12: 
> > 00044472
> > [   38.615758] R13: 000f R14: c42caa68 R15: 
> > 0010
> > [   38.615760] FS:  7effa30c2700() GS:880ffd5e() 
> > knlGS:
> > [   38.615761] CS:  0010 DS:  ES:  CR0: 80050033
> > [   38.615762] CR2: 7f19e3c29320 CR3: 000f9f9a3000 CR4: 
> > 001407e0
> > [   38.615763] Stack:
> > [   38.615765]  c42caa20 880ffd5e3d38 8140e524 
> > 1000
> > [   38.615767]  03e9 0400 0002 
> > 880ffd5e3d48
> > [   38.615769]  8140e43f 880ffd5e3d58 8140e477 
> > 880ffd5e3d78
> > [   38.615769] Call Trace:
> > [   38.615771]  
> > [   38.615779]  [] delay_tsc+0x44/0xd0
> > [   38.615782]  [] __delay+0xf/0x20
> > [   38.615784]  [] __const_udelay+0x27/0x30
> > [   38.615788]  [] 
> > native_safe_apic_wait_icr_idle+0x2a/0x60
> > [   38.615792]  [] 
> > default_send_IPI_mask_sequence_phys+0xc0/0xe0
> > [   38.615798]  [] physflat_send_IPI_all+0x17/0x20
> > [   38.615801]  [] 
> > arch_trigger_all_cpu_backtrace+0x70/0xb0
> > [   38.615807]  [] rcu_check_callbacks+0x4f1/0x840
> > [   38.615814]  [] ? raise_softirq_irqoff+0xe/0x40
> > [   38.615821]  [] update_process_times+0x42/0x70
> > [   38.615826]  [] tick_sched_handle.isra.15+0x36/0x50
> > [   38.615829]  [] tick_sched_timer+0x44/0x70
> > [   38.615835]  [] __run_hrtimer+0x9b/0x2a0
> > [   38.615838]  [] ? 

[GIT PULL] More ACPI and power management updates for 3.20-rc1

[Rafael J. Wysocki]

Hi Linus,

Please pull from

 git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git \
 pm+acpi-3.20-rc1-2

to receive more ACPI and power management material for v3.20-rc1 with
top-most commit c7fb90dfbef49b03e6f3fd6a32338e59cbcf34ee

 Merge branches 'pm-cpufreq', 'pm-cpuidle', 'pm-devfreq', 'pm-opp' and
'pm-tools'

on top of commit 872912352c5be930e9568e5f3b6d73107d9f278d

 Merge tag 'pm+acpi-3.20-rc1' of
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm

These are two reverts related to system suspend breakage by one of
a recent commits, a fix for a recently introduced bug in devfreq
and a bunch of other things that didn't make it into my previous
pull request, but otherwise are ready to go.

Specifics:

 - Revert two ACPI EC driver commits, one that broke system suspend
   on Acer Aspire S5 and one that depends on it (Rafael J Wysocki).

 - Fix a typo leading to an incorrect check in the exynos-ppmu devfreq
   driver (Dan Carpenter).

 - Add support for one more Broadwell CPU model to intel_idle (Len Brown).

 - Fix an obscure problem with state transitions related to interrupts
   in the speedstep-smi cpufreq driver (Mikulas Patocka).

 - Remove some unnecessary messages related to the "out of memory"
   condition from the core PM code (Quentin Lambert).

 - Update turbostat parameters and documentation, add support for
   one more Broadwell CPU model to it and modify it to skip
   printing disabled package C-states (Len Brown).

Thanks!


---

Dan Carpenter (1):
  PM / devfreq: event: testing the wrong variable

Len Brown (4):
  tools/power turbostat: Skip printing disabled package C-states
  tools/power turbostat: update parameters, documentation
  intel_idle: support additional Broadwell model
  tools/power turbostat: support additional Broadwell model

Mikulas Patocka (1):
  cpufreq: speedstep-smi: enable interrupts when waiting

Quentin Lambert (1):
  PM / OPP / clk: Remove unnecessary OOM message

Rafael J. Wysocki (2):
  Revert "ACPI / EC: Add GPE reference counting debugging messages"
  Revert "ACPI / EC: Add query flushing support"

---

 drivers/acpi/ec.c | 125 ++--
 drivers/base/firmware_class.c |   1 -
 drivers/base/power/clock_ops.c|   4 +-
 drivers/base/power/opp.c  |   8 +-
 drivers/cpufreq/speedstep-lib.c   |   3 +
 drivers/cpufreq/speedstep-smi.c   |  12 ++
 drivers/devfreq/event/exynos-ppmu.c   |   4 +-
 drivers/idle/intel_idle.c |   1 +
 tools/power/x86/turbostat/turbostat.8 |  68 ---
 tools/power/x86/turbostat/turbostat.c | 344 +-
 10 files changed, 293 insertions(+), 277 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 RT v2] kernel/res_counter.c: Change lock of struct res_counter to raw_spinlock_t

[Thavatchai Makphaibulchoke]

On 02/13/2015 12:19 PM, Paul Gortmaker wrote:
> 
> I think there is more to this issue than just a lock conversion.
> Firstly, if we look at the existing -rt patches, we've got the old
> patch from ~2009 that is:
> 

Thanks Paul for testing and reporting the problem.

Yes, looks like the issue probably involve more than converting to a
raw_spinlock_t.

>  From: Ingo Molnar 
>  Date: Fri, 3 Jul 2009 08:44:33 -0500
>  Subject: [PATCH] core: Do not disable interrupts on RT in res_counter.c
> 
> which changed the local_irq_save to local_irq_save_nort in order to
> avoid such a raw lock conversion.
> 

The patch did not quite state explicitly that the fix was to avoid raw
lock conversion.  I guess one could infer so.

Anyway as the patch also mentioned, the code needs a second look.

I'll try to see if I could rework my patch.

> Also, when I test this patch on a larger machine with lots of cores, I
> get boot up issues (general protection fault while trying to access the
> raw lock) or RCU stalls that trigger broadcast NMI backtraces; both which
> implicate the same code area, and they go away with a revert.
> 

Could you please let me know how many cores/threads you are running.

Could you please also send me a stack trace for the protection fault
problem, if available.

Thanks again for reporting the problem.

Thanks,
Mak.


> Stuff like the below. Figured I'd better mention it since Steve was
> talking about rounding up patches for stable, and the solution to the
> original problem reported here seems to need to be revisited.
> 
> Paul.
> --
> 
> 
> [   38.615736] NMI backtrace for cpu 15
> [   38.615739] CPU: 15 PID: 835 Comm: ovirt-engine.py Not tainted 
> 3.14.33-rt28-WR7.0.0.0_ovp+ #3
> [   38.615740] Hardware name: Intel Corporation S2600CP/S2600CP, BIOS 
> SE5C600.86B.02.01.0002.082220131453 08/22/2013
> [   38.615742] task: 880faca8 ti: 880f9d89 task.ti: 
> 880f9d89
> [   38.615751] RIP: 0010:[]  [] 
> preempt_count_add+0x41/0xb0
> [   38.615752] RSP: 0018:880ffd5e3d00  EFLAGS: 0097
> [   38.615754] RAX: 00010002 RBX: 0001 RCX: 
> 
> [   38.615755] RDX:  RSI: 0100 RDI: 
> 0001
> [   38.615756] RBP: 880ffd5e3d08 R08: 82317700 R09: 
> 0028
> [   38.615757] R10: 000f R11: 00017484 R12: 
> 00044472
> [   38.615758] R13: 000f R14: c42caa68 R15: 
> 0010
> [   38.615760] FS:  7effa30c2700() GS:880ffd5e() 
> knlGS:
> [   38.615761] CS:  0010 DS:  ES:  CR0: 80050033
> [   38.615762] CR2: 7f19e3c29320 CR3: 000f9f9a3000 CR4: 
> 001407e0
> [   38.615763] Stack:
> [   38.615765]  c42caa20 880ffd5e3d38 8140e524 
> 1000
> [   38.615767]  03e9 0400 0002 
> 880ffd5e3d48
> [   38.615769]  8140e43f 880ffd5e3d58 8140e477 
> 880ffd5e3d78
> [   38.615769] Call Trace:
> [   38.615771]  
> [   38.615779]  [] delay_tsc+0x44/0xd0
> [   38.615782]  [] __delay+0xf/0x20
> [   38.615784]  [] __const_udelay+0x27/0x30
> [   38.615788]  [] native_safe_apic_wait_icr_idle+0x2a/0x60
> [   38.615792]  [] 
> default_send_IPI_mask_sequence_phys+0xc0/0xe0
> [   38.615798]  [] physflat_send_IPI_all+0x17/0x20
> [   38.615801]  [] arch_trigger_all_cpu_backtrace+0x70/0xb0
> [   38.615807]  [] rcu_check_callbacks+0x4f1/0x840
> [   38.615814]  [] ? raise_softirq_irqoff+0xe/0x40
> [   38.615821]  [] update_process_times+0x42/0x70
> [   38.615826]  [] tick_sched_handle.isra.15+0x36/0x50
> [   38.615829]  [] tick_sched_timer+0x44/0x70
> [   38.615835]  [] __run_hrtimer+0x9b/0x2a0
> [   38.615838]  [] ? tick_sched_handle.isra.15+0x50/0x50
> [   38.615842]  [] hrtimer_interrupt+0x12e/0x2e0
> [   38.615845]  [] local_apic_timer_interrupt+0x37/0x60
> [   38.615851]  [] smp_apic_timer_interrupt+0x3f/0x50
> [   38.615854]  [] apic_timer_interrupt+0x6a/0x70
> [   38.615855]  
> [   38.615861]  [] ? __res_counter_charge+0xc4/0x170
> [   38.615866]  [] ? _raw_spin_lock+0x47/0x60
> [   38.615882]  [] ? _raw_spin_lock+0x17/0x60
> [   38.615885]  [] __res_counter_charge+0xc4/0x170
> [   38.615888]  [] res_counter_charge+0x10/0x20
> [   38.615896]  [] vm_cgroup_charge_shmem+0x35/0x50
> [   38.615900]  [] shmem_getpage_gfp+0x4b6/0x8e0
> [   38.615904]  [] ? get_parent_ip+0xd/0x50
> [   38.615908]  [] shmem_symlink+0xe6/0x210
> [   38.615914]  [] ? __inode_permission+0x41/0xd0
> [   38.615917]  [] vfs_symlink+0x90/0xd0
> [   38.615923]  [] SyS_symlinkat+0x62/0xc0
> [   38.615927]  [] SyS_symlink+0x16/0x20
> [   38.615930]  [] system_call_fastpath+0x1a/0x1f
> 
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.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/3] Slab infrastructure for array operations

[David Rientjes]

On Fri, 13 Feb 2015, Christoph Lameter wrote:

> > I also think that this implementation is slub-specific. For example,
> > in slab case, it is always better to access local cpu cache first than
> > page allocator since slab doesn't use list to manage free objects and
> > there is no cache line overhead like as slub. I think that,
> > in kmem_cache_alloc_array(), just call to allocator-defined
> > __kmem_cache_alloc_array() is better approach.
> 
> What do you mean by "better"? Please be specific as to where you would see
> a difference. And slab definititely manages free objects although
> differently than slub. SLAB manages per cpu (local) objects, per node
> partial lists etc. Same as SLUB. The cache line overhead is there but no
> that big a difference in terms of choosing objects to get first.
> 

I think because we currently lack a non-fallback implementation for slab 
that it may be premature to discuss what would be unified if such an 
implementation were to exist.  That unification can always happen later 
if/when the slab implementation is proposed, but I don't think we should 
be unifying an implementation that doesn't exist.  

In other words, I think it would be much cleaner to do just define the 
generic array alloc and array free functions in mm/slab_common.c along 
with their EXPORT_SYMBOL()'s as simple callbacks to per-allocator 
__kmem_cache_{alloc,free}_array() implementations.  I think it's also 
better from a source code perspective to avoid reading two different 
functions and then realizing that nothing is actually unified between them 
(and the absence of an unnecessary #ifdef is currently helpful).
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v4 2/2] x86, arm, platform, xen, kconfig: add xen defconfig helper

[David Rientjes]

On Fri, 13 Feb 2015, Luis R. Rodriguez wrote:

> David,
> 
> since I'm making some Kconfig changes to Xen I think I should
> fold this into that series with the modifications required
> last so as to avoid other commits and have this go in clean
> after all the changes, and have this go through you with
> that.
> 
> Thoughts?
> 

Sure, if you're planning on kconfig changes then I agree that this should 
come later, either as part of the same patchset if it logically makes 
sense or just in a follow-up patchset.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3 1/3] lib: find_*_bit reimplementation

[George Spelvin]

> Ohh... I used to think I know something about optimization. I tried build
> Rasmus' 'find_last_bit' against mine on MIPS, and found that sizes are as
> 268 vs 320 bytes. I think the best version is suggested by George, both
> readable, and effective. What about using it? If no objections, I'll
> gather all fixes and upload new patchset this weekend.

I'll happily ack whichever you prefer.  Tightening the code to the
maximum possible fun exercise, but not essential.  However, I finally
got GCC to generate reasonable code with the following:

size_t find_last_bit3(const unsigned long *addr, size_t size)
{
if (size) {
unsigned long val = LAST_WORD_MASK(size);
size_t idx = (size-1) / BITS_PER_LONG;

do {
val &= addr[idx];
if (val)
return idx * BITS_PER_LONG + __fls(val);
val = ~0ul;
} while (idx--);
}
return size;
}

size_t find_last_bit4(const unsigned long *addr, size_t size)
{
if (size) {
unsigned long val = LAST_WORD_MASK(size);
size_t idx = DIV_ROUND_UP(size, BITS_PER_LONG);

do {
val &= addr[idx];
if (val)
return idx * BITS_PER_LONG + __fls(val);
val = ~0ul;
} while (--idx);
}
return size;
}

Which produced, respectively, 76 and 68-byte functions:

 :
   0:   31 c0   xor%eax,%eax
   2:   48 85 f6test   %rsi,%rsi
   5:   74 44   je 4b 
   7:   48 8d 46 ff lea-0x1(%rsi),%rax
   b:   89 f1   mov%esi,%ecx
   d:   48 c7 c2 ff ff ff ffmov$0x,%rdx
  14:   f7 d9   neg%ecx
  16:   48 c1 e8 06 shr$0x6,%rax
  1a:   48 d3 eashr%cl,%rdx
  1d:   eb 11   jmp30 
  1f:   90  nop
  20:   48 83 e8 01 sub$0x1,%rax
  24:   48 c7 c2 ff ff ff ffmov$0x,%rdx
  2b:   48 39 d0cmp%rdx,%rax
  2e:   74 18   je 48 
  30:   48 23 14 c7 and(%rdi,%rax,8),%rdx
  34:   74 ea   je 20 
  36:   48 c1 e0 06 shl$0x6,%rax
  3a:   48 0f bd d2 bsr%rdx,%rdx
  3e:   48 01 d0add%rdx,%rax
  41:   c3  retq   
  42:   66 0f 1f 44 00 00   nopw   0x0(%rax,%rax,1)
  48:   48 89 f0mov%rsi,%rax
  4b:   c3  retq   
  4c:   0f 1f 40 00 nopl   0x0(%rax)

0050 :
  50:   31 c0   xor%eax,%eax
  52:   48 85 f6test   %rsi,%rsi
  55:   74 3c   je 93 
  57:   48 8d 46 3f lea0x3f(%rsi),%rax
  5b:   89 f1   mov%esi,%ecx
  5d:   48 c7 c2 ff ff ff ffmov$0x,%rdx
  64:   f7 d9   neg%ecx
  66:   48 c1 e8 06 shr$0x6,%rax
  6a:   48 d3 eashr%cl,%rdx
  6d:   eb 0d   jmp7c 
  6f:   90  nop
  70:   48 c7 c2 ff ff ff ffmov$0x,%rdx
  77:   48 01 d0add%rdx,%rax
  7a:   74 14   je 90 
  7c:   48 23 14 c7 and(%rdi,%rax,8),%rdx
  80:   74 ee   je 70 
  82:   48 c1 e0 06 shl$0x6,%rax
  86:   48 0f bd d2 bsr%rdx,%rdx
  8a:   48 01 d0add%rdx,%rax
  8d:   c3  retq   
  8e:   66 90   xchg   %ax,%ax
  90:   48 89 f0mov%rsi,%rax
  93:   c3  retq   

The second one omits all the unwanted tests & compares, and even does
something clever with the -1 mask that I didn't think of.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.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] sched/completion: completion_done() should serialize with complete()

[Paul E. McKenney]

On Thu, Feb 12, 2015 at 08:59:13PM +0100, Oleg Nesterov wrote:
> Commit de30ec47302c "Remove unnecessary ->wait.lock serialization when
> reading completion state" was not correct, without lock/unlock the code
> like stop_machine_from_inactive_cpu()
> 
>   while (!completion_done())
>   cpu_relax();
> 
> can return before complete() finishes its spin_unlock() which writes to
> this memory. And spin_unlock_wait().
> 
> While at it, change try_wait_for_completion() to use READ_ONCE().
> 
> Reported-by: "Paul E. McKenney" 
> Reported-by: Davidlohr Bueso 
> Signed-off-by: Oleg Nesterov 

So I am having some difficulty reproducing the original problem, but
the patch passes rcutorture testing.  So...

Tested-by: Paul E. McKenney 

> --- x/kernel/sched/completion.c
> +++ x/kernel/sched/completion.c
> @@ -274,7 +274,7 @@ bool try_wait_for_completion(struct comp
>* first without taking the lock so we can
>* return early in the blocking case.
>*/
> - if (!ACCESS_ONCE(x->done))
> + if (!READ_ONCE(x->done))
>   return 0;
> 
>   spin_lock_irqsave(>wait.lock, flags);
> @@ -297,6 +297,11 @@ EXPORT_SYMBOL(try_wait_for_completion);
>   */
>  bool completion_done(struct completion *x)
>  {
> - return !!ACCESS_ONCE(x->done);
> + if (!READ_ONCE(x->done))
> + return false;
> +
> + smp_rmb();
> + spin_unlock_wait(>wait.lock);
> + return true;
>  }
>  EXPORT_SYMBOL(completion_done);
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 03/43] tools build: Add subdir support

[Arnaldo Carvalho de Melo]

From: Jiri Olsa 

Add support to make directory any time we build objects out of the tree
(O=/tmp/krava) and the output directory does not exist.

Signed-off-by: Jiri Olsa 
Tested-by: Sukadev Bhattiprolu 
Tested-by: Will Deacon 
Cc: Alexis Berlemont 
Cc: Borislav Petkov 
Cc: Corey Ashford 
Cc: David Ahern 
Cc: Frederic Weisbecker 
Cc: Namhyung Kim 
Cc: Paul Mackerras 
Cc: Peter Zijlstra 
Cc: Stephane Eranian 
Link: http://lkml.kernel.org/n/tip-h80ukls4o2kpr0e4c4bfl...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/build/Makefile.build | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/tools/build/Makefile.build b/tools/build/Makefile.build
index 35174d920476..692e1b154200 100644
--- a/tools/build/Makefile.build
+++ b/tools/build/Makefile.build
@@ -37,6 +37,11 @@ subdir-obj-y :=
 build-file := $(dir)/Build
 include $(build-file)
 
+# Create directory unless it exists
+quiet_cmd_mkdir = MKDIR$(dir $@)
+  cmd_mkdir = mkdir -p $(dir $@)
+ rule_mkdir = $(if $(wildcard $(dir $@)),,@$(call echo-cmd,mkdir) 
$(cmd_mkdir))
+
 # Compile command
 quiet_cmd_cc_o_c = CC   $@
   cmd_cc_o_c = $(CC) $(c_flags) -c -o $@ $<
@@ -49,9 +54,11 @@ quiet_cmd_ld_multi = LD   $@
 
 # Build rules
 $(OUTPUT)%.o: %.c FORCE
+   $(call rule_mkdir)
$(call if_changed_dep,cc_o_c)
 
 $(OUTPUT)%.o: %.S FORCE
+   $(call rule_mkdir)
$(call if_changed_dep,cc_o_c)
 
 # Gather build data:
-- 
1.9.3

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

Re: [RFC PATCH 8/9] livepatch: allow patch modules to be removed

[Josh Poimboeuf]

On Fri, Feb 13, 2015 at 05:17:10PM +0100, Miroslav Benes wrote:
> On Fri, 13 Feb 2015, Josh Poimboeuf wrote:
> > Hm, even with Jiri Slaby's suggested fix to add the completion to the
> > unregister path, I still get a lockdep warning.  This looks more insidious,
> > related to the locking order of a kernfs lock and the klp lock.  I'll need 
> > to
> > look at this some more...
> 
> Yes, I was afraid of this. Lockdep warning is a separate bug. It is caused 
> by taking klp_mutex in enabled_store. During rmmod klp_unregister_patch 
> takes klp_mutex and destroys the sysfs structure. If somebody writes to 
> enabled just after unregister takes the mutex and before the sysfs 
> removal, he would cause the deadlock, because enabled_store takes the 
> "sysfs lock" and then klp_mutex. That is exactly what the lockdep tells us 
> below.
> 
> We can look for inspiration elsewhere. Grep for s_active through git log 
> of the mainline offers several commits which dealt exactly with this. Will 
> browse through that...

Thanks Miroslav, please let me know what you find.  It wouldn't surprise
me if this were a very common problem.

One option would be to move the enabled_store() work out to a workqueue
or something.

> > 
> > To recreate:
> > 
> > insmod livepatch-sample.ko
> > 
> > # wait for patching to complete
> > 
> > ~/a.out &  <-- simple program which opens the "enabled" file in the 
> > background
> 
> I didn't even need such a program. Lockdep warned me with sole insmod, 
> echo and rmmod. It is magically clever.

Ah, even easier... lockdep is awesome.

-- 
Josh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.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] ARM: smp: Only expose /sys/.../cpuX/online if hotpluggable

[Stephen Boyd]

On 02/13/15 12:54, Magnus Damm wrote:
> Hi Stephen,
>
> On Fri, Feb 13, 2015 at 8:23 PM, Stephen Boyd  wrote:
>> On 02/13/15 12:20, Simon Horman wrote:
>>> Hi Stephen,
>>>
>>> On Fri, Feb 13, 2015 at 10:06:39AM -0800, Stephen Boyd wrote:
 diff --git a/arch/arm/mach-shmobile/smp-r8a7779.c 
 b/arch/arm/mach-shmobile/smp-r8a7779.c
 index 3f761f839043..b45206f93ddf 100644
 --- a/arch/arm/mach-shmobile/smp-r8a7779.c
 +++ b/arch/arm/mach-shmobile/smp-r8a7779.c
 @@ -124,19 +124,12 @@ static int r8a7779_cpu_kill(unsigned int cpu)

  return 0;
  }
 -
 -static int r8a7779_cpu_disable(unsigned int cpu)
 -{
 -/* only CPU1->3 have power domains, do not allow hotplug of CPU0 */
 -return cpu == 0 ? -EPERM : 0;
 -}
  #endif /* CONFIG_HOTPLUG_CPU */

  struct smp_operations r8a7779_smp_ops  __initdata = {
  .smp_prepare_cpus   = r8a7779_smp_prepare_cpus,
  .smp_boot_secondary = r8a7779_boot_secondary,
  #ifdef CONFIG_HOTPLUG_CPU
 -.cpu_disable= r8a7779_cpu_disable,
  .cpu_die= shmobile_smp_scu_cpu_die,
  .cpu_kill   = r8a7779_cpu_kill,
  #endif
>>> Its not clear to me why r8a7779_cpu_disable() has been
>>> removed rather than replaced by r8a7779_cpu_can_disable()
>> By default ARM's smp.c assumes that CPU0 can't be hotplugged. The
>> function is redundant. I guess I should have mentioned that in the
>> commit text.
> Thanks for your efforts. Can you please tell me where that limitation
> is located? I'm quite sure I've brought CPU cores up and down
> including CPU0, but maybe something is missing?
>
>

The assumption is made if there isn't a cpu_disable (now
cpu_can_disable) op. See platform_cpu_disable() in
arch/arm/kernel/smp.c. If there isn't such a limitation on a particular
platform, the platform needs to set the cpu_disable/cpu_can_disable op
and indicate that there isn't a limitation (by returning 1 for example).

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

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

[PATCH 15/43] perf build: Add gtk objects building

[Arnaldo Carvalho de Melo]

From: Jiri Olsa 

Move the gtk objects building under build framework.

Add new gtk build object so it's separated from the rest of the code and
could be librarized.

Signed-off-by: Jiri Olsa 
Tested-by: Sukadev Bhattiprolu 
Tested-by: Will Deacon 
Cc: Alexis Berlemont 
Cc: Borislav Petkov 
Cc: Corey Ashford 
Cc: David Ahern 
Cc: Frederic Weisbecker 
Cc: Namhyung Kim 
Cc: Paul Mackerras 
Cc: Peter Zijlstra 
Cc: Stephane Eranian 
Link: http://lkml.kernel.org/n/tip-cd27z7vww85nxdq37rkjk...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/Build   |  2 ++
 tools/perf/Makefile.perf   | 17 +
 tools/perf/config/Makefile |  1 +
 tools/perf/ui/gtk/Build|  9 +
 4 files changed, 17 insertions(+), 12 deletions(-)
 create mode 100644 tools/perf/ui/gtk/Build

diff --git a/tools/perf/Build b/tools/perf/Build
index e84ced325147..a9ff8fd0bff9 100644
--- a/tools/perf/Build
+++ b/tools/perf/Build
@@ -35,3 +35,5 @@ CFLAGS_builtin-timechart.o += $(paths)
 libperf-y += util/
 libperf-y += arch/
 libperf-y += ui/
+
+gtk-y += ui/gtk/
diff --git a/tools/perf/Makefile.perf b/tools/perf/Makefile.perf
index d9de8af55de2..18ff8aab582a 100644
--- a/tools/perf/Makefile.perf
+++ b/tools/perf/Makefile.perf
@@ -341,14 +341,7 @@ endif
 
 ifndef NO_GTK2
   ALL_PROGRAMS += $(OUTPUT)libperf-gtk.so
-
-  GTK_OBJS += $(OUTPUT)ui/gtk/browser.o
-  GTK_OBJS += $(OUTPUT)ui/gtk/hists.o
-  GTK_OBJS += $(OUTPUT)ui/gtk/setup.o
-  GTK_OBJS += $(OUTPUT)ui/gtk/util.o
-  GTK_OBJS += $(OUTPUT)ui/gtk/helpline.o
-  GTK_OBJS += $(OUTPUT)ui/gtk/progress.o
-  GTK_OBJS += $(OUTPUT)ui/gtk/annotate.o
+  GTK_IN := $(OUTPUT)gtk-in.o
 
 install-gtk: $(OUTPUT)libperf-gtk.so
$(call QUIET_INSTALL, 'GTK UI') \
@@ -416,10 +409,10 @@ $(OUTPUT)perf: $(OUTPUT)perf.o $(BUILTIN_OBJS) 
$(PERFLIBS) $(PERF_IN)
$(QUIET_LINK)$(CC) $(CFLAGS) $(LDFLAGS) $(OUTPUT)perf.o \
$(BUILTIN_OBJS) $(PERF_IN) $(LIBS) -o $@
 
-$(GTK_OBJS): $(OUTPUT)%.o: %.c $(LIB_H)
-   $(QUIET_CC)$(CC) -o $@ -c -fPIC $(CFLAGS) $(GTK_CFLAGS) $<
+$(GTK_IN): FORCE
+   @$(MAKE) $(build)=gtk
 
-$(OUTPUT)libperf-gtk.so: $(GTK_OBJS) $(PERFLIBS)
+$(OUTPUT)libperf-gtk.so: $(GTK_IN) $(PERFLIBS)
$(QUIET_LINK)$(CC) -o $@ -shared $(LDFLAGS) $(filter %.o,$^) $(GTK_LIBS)
 
 $(OUTPUT)common-cmds.h: util/generate-cmdlist.sh command-list.txt
@@ -699,7 +692,7 @@ config-clean:
@$(MAKE) -C config/feature-checks clean >/dev/null
 
 clean: $(LIBTRACEEVENT)-clean $(LIBAPIKFS)-clean config-clean
-   $(call QUIET_CLEAN, core-objs)  $(RM) $(LIB_OBJS) $(BUILTIN_OBJS) 
$(LIB_FILE) $(OUTPUT)perf-archive $(OUTPUT)perf-with-kcore $(OUTPUT)perf.o 
$(LANG_BINDINGS) $(GTK_OBJS)
+   $(call QUIET_CLEAN, core-objs)  $(RM) $(LIB_OBJS) $(BUILTIN_OBJS) 
$(LIB_FILE) $(OUTPUT)perf-archive $(OUTPUT)perf-with-kcore $(OUTPUT)perf.o 
$(LANG_BINDINGS)
@find . -name '*.o' -delete -o -name '\.*.cmd' -delete -o -name '\.*.d' 
-delete
@$(RM) .config-detected
$(call QUIET_CLEAN, core-progs) $(RM) $(ALL_PROGRAMS) perf 
perf-read-vdso32 perf-read-vdsox32
diff --git a/tools/perf/config/Makefile b/tools/perf/config/Makefile
index 4b251114b34d..6b9678248694 100644
--- a/tools/perf/config/Makefile
+++ b/tools/perf/config/Makefile
@@ -846,3 +846,4 @@ $(call detected_var,ETC_PERFCONFIG_SQ)
 $(call detected_var,prefix_SQ)
 $(call detected_var,perfexecdir_SQ)
 $(call detected_var,LIBDIR)
+$(call detected_var,GTK_CFLAGS)
diff --git a/tools/perf/ui/gtk/Build b/tools/perf/ui/gtk/Build
new file mode 100644
index ..ec22e899a224
--- /dev/null
+++ b/tools/perf/ui/gtk/Build
@@ -0,0 +1,9 @@
+CFLAGS_gtk += -fPIC $(GTK_CFLAGS)
+
+gtk-y += browser.o
+gtk-y += hists.o
+gtk-y += setup.o
+gtk-y += util.o
+gtk-y += helpline.o
+gtk-y += progress.o
+gtk-y += annotate.o
-- 
1.9.3

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

[PATCH 13/43] perf build: Add ui objects building

[Arnaldo Carvalho de Melo]

From: Jiri Olsa 

Move the ui objects building under build framework to be included in the
libperf build object.

Signed-off-by: Jiri Olsa 
Tested-by: Sukadev Bhattiprolu 
Tested-by: Will Deacon 
Cc: Alexis Berlemont 
Cc: Borislav Petkov 
Cc: Corey Ashford 
Cc: David Ahern 
Cc: Frederic Weisbecker 
Cc: Namhyung Kim 
Cc: Paul Mackerras 
Cc: Peter Zijlstra 
Cc: Stephane Eranian 
Link: http://lkml.kernel.org/n/tip-re5vuat8uu396n7hyor9b...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/Build   |  1 +
 tools/perf/Makefile.perf   | 10 --
 tools/perf/config/Makefile |  1 +
 tools/perf/ui/Build|  8 
 4 files changed, 10 insertions(+), 10 deletions(-)
 create mode 100644 tools/perf/ui/Build

diff --git a/tools/perf/Build b/tools/perf/Build
index 170e4563bb24..e84ced325147 100644
--- a/tools/perf/Build
+++ b/tools/perf/Build
@@ -34,3 +34,4 @@ CFLAGS_builtin-timechart.o += $(paths)
 
 libperf-y += util/
 libperf-y += arch/
+libperf-y += ui/
diff --git a/tools/perf/Makefile.perf b/tools/perf/Makefile.perf
index 96e3cdc7f89c..c658fa6dc81e 100644
--- a/tools/perf/Makefile.perf
+++ b/tools/perf/Makefile.perf
@@ -327,13 +327,6 @@ LIB_H += util/data.h
 LIB_H += util/kvm-stat.h
 LIB_H += util/thread-stack.h
 
-LIB_OBJS += $(OUTPUT)ui/setup.o
-LIB_OBJS += $(OUTPUT)ui/helpline.o
-LIB_OBJS += $(OUTPUT)ui/progress.o
-LIB_OBJS += $(OUTPUT)ui/util.o
-LIB_OBJS += $(OUTPUT)ui/hist.o
-LIB_OBJS += $(OUTPUT)ui/stdio/hist.o
-
 PERFLIBS = $(LIB_FILE) $(LIBAPIKFS) $(LIBTRACEEVENT)
 
 # We choose to avoid "if .. else if .. else .. endif endif"
@@ -491,9 +484,6 @@ $(OUTPUT)%.o: %.S
 $(OUTPUT)%.s: %.S
$(QUIET_CC)$(CC) -o $@ -E $(CFLAGS) $<
 
-$(OUTPUT)ui/setup.o: ui/setup.c $(OUTPUT)PERF-CFLAGS
-   $(QUIET_CC)$(CC) -o $@ -c $(CFLAGS) -DLIBDIR='"$(libdir_SQ)"' $<
-
 $(OUTPUT)ui/browser.o: ui/browser.c $(OUTPUT)PERF-CFLAGS
$(QUIET_CC)$(CC) -o $@ -c $(CFLAGS) -DENABLE_SLFUTURE_CONST $<
 
diff --git a/tools/perf/config/Makefile b/tools/perf/config/Makefile
index e55d811e633f..07391389aa4c 100644
--- a/tools/perf/config/Makefile
+++ b/tools/perf/config/Makefile
@@ -844,3 +844,4 @@ $(call detected_var,mandir_SQ)
 $(call detected_var,ETC_PERFCONFIG_SQ)
 $(call detected_var,prefix_SQ)
 $(call detected_var,perfexecdir_SQ)
+$(call detected_var,LIBDIR)
diff --git a/tools/perf/ui/Build b/tools/perf/ui/Build
new file mode 100644
index ..077b6a448ddc
--- /dev/null
+++ b/tools/perf/ui/Build
@@ -0,0 +1,8 @@
+libperf-y += setup.o
+libperf-y += helpline.o
+libperf-y += progress.o
+libperf-y += util.o
+libperf-y += hist.o
+libperf-y += stdio/hist.o
+
+CFLAGS_setup.o += -DLIBDIR="BUILD_STR($(LIBDIR))"
-- 
1.9.3

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

[PATCH 10/43] perf build: Add probe objects building

[Arnaldo Carvalho de Melo]

From: Jiri Olsa 

Move the probe objects building under build framework to be included in
the libperf build object.

Signed-off-by: Jiri Olsa 
Tested-by: Sukadev Bhattiprolu 
Tested-by: Will Deacon 
Cc: Alexis Berlemont 
Cc: Borislav Petkov 
Cc: Corey Ashford 
Cc: David Ahern 
Cc: Frederic Weisbecker 
Cc: Namhyung Kim 
Cc: Paul Mackerras 
Cc: Peter Zijlstra 
Cc: Stephane Eranian 
Link: http://lkml.kernel.org/n/tip-p39iitiu2ltgmtbn48bsh...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/Build   |  1 +
 tools/perf/Makefile.perf   | 19 +--
 tools/perf/config/Makefile |  1 +
 tools/perf/util/Build  |  7 +++
 4 files changed, 10 insertions(+), 18 deletions(-)

diff --git a/tools/perf/Build b/tools/perf/Build
index 31c4c555cc81..170e4563bb24 100644
--- a/tools/perf/Build
+++ b/tools/perf/Build
@@ -20,6 +20,7 @@ perf-y += builtin-inject.o
 perf-y += builtin-mem.o
 
 perf-$(CONFIG_AUDIT) += builtin-trace.o
+perf-$(CONFIG_LIBELF) += builtin-probe.o
 
 perf-y += bench/
 perf-y += tests/
diff --git a/tools/perf/Makefile.perf b/tools/perf/Makefile.perf
index 8951cd9809a2..0997e2b33c77 100644
--- a/tools/perf/Makefile.perf
+++ b/tools/perf/Makefile.perf
@@ -327,9 +327,6 @@ LIB_H += util/data.h
 LIB_H += util/kvm-stat.h
 LIB_H += util/thread-stack.h
 
-LIB_OBJS += $(OUTPUT)util/symbol-elf.o
-LIB_OBJS += $(OUTPUT)util/probe-event.o
-
 LIB_OBJS += $(OUTPUT)ui/setup.o
 LIB_OBJS += $(OUTPUT)ui/helpline.o
 LIB_OBJS += $(OUTPUT)ui/progress.o
@@ -337,8 +334,6 @@ LIB_OBJS += $(OUTPUT)ui/util.o
 LIB_OBJS += $(OUTPUT)ui/hist.o
 LIB_OBJS += $(OUTPUT)ui/stdio/hist.o
 
-BUILTIN_OBJS += $(OUTPUT)builtin-probe.o
-
 PERFLIBS = $(LIB_FILE) $(LIBAPIKFS) $(LIBTRACEEVENT)
 
 # We choose to avoid "if .. else if .. else .. endif endif"
@@ -351,19 +346,7 @@ ifneq ($(OUTPUT),)
   CFLAGS += -I$(OUTPUT)
 endif
 
-ifdef NO_LIBELF
-# Remove ELF/DWARF dependent codes
-LIB_OBJS := $(filter-out $(OUTPUT)util/symbol-elf.o,$(LIB_OBJS))
-LIB_OBJS := $(filter-out $(OUTPUT)util/dwarf-aux.o,$(LIB_OBJS))
-LIB_OBJS := $(filter-out $(OUTPUT)util/probe-event.o,$(LIB_OBJS))
-LIB_OBJS := $(filter-out $(OUTPUT)util/probe-finder.o,$(LIB_OBJS))
-
-BUILTIN_OBJS := $(filter-out $(OUTPUT)builtin-probe.o,$(BUILTIN_OBJS))
-
-# Use minimal symbol handling
-LIB_OBJS += $(OUTPUT)util/symbol-minimal.o
-
-else # NO_LIBELF
+ifndef NO_LIBELF
 ifndef NO_DWARF
   LIB_OBJS += $(OUTPUT)util/probe-finder.o
   LIB_OBJS += $(OUTPUT)util/dwarf-aux.o
diff --git a/tools/perf/config/Makefile b/tools/perf/config/Makefile
index 5b89bb7b2d7d..79ee4ccce3dc 100644
--- a/tools/perf/config/Makefile
+++ b/tools/perf/config/Makefile
@@ -371,6 +371,7 @@ endif # NO_LIBELF
 ifndef NO_LIBELF
   CFLAGS += -DHAVE_LIBELF_SUPPORT
   EXTLIBS += -lelf
+  $(call detected,CONFIG_LIBELF)
 
   ifeq ($(feature-libelf-mmap), 1)
 CFLAGS += -DHAVE_LIBELF_MMAP_SUPPORT
diff --git a/tools/perf/util/Build b/tools/perf/util/Build
index c107f309d29f..73a0411e2014 100644
--- a/tools/perf/util/Build
+++ b/tools/perf/util/Build
@@ -75,6 +75,13 @@ libperf-y += tsc.o
 libperf-y += cloexec.o
 libperf-y += thread-stack.o
 
+libperf-$(CONFIG_LIBELF) += symbol-elf.o
+libperf-$(CONFIG_LIBELF) += probe-event.o
+
+ifndef CONFIG_LIBELF
+libperf-y += symbol-minimal.o
+endif
+
 CFLAGS_config.o   += -DETC_PERFCONFIG="BUILD_STR($(ETC_PERFCONFIG_SQ))"
 CFLAGS_exec_cmd.o += -DPERF_EXEC_PATH="BUILD_STR($(perfexecdir_SQ))" 
-DPREFIX="BUILD_STR($(prefix_SQ))"
 
-- 
1.9.3

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

Re: [PATCHv2] perf/stat: Report unsupported events properly

[Arnaldo Carvalho de Melo]

Em Fri, Feb 13, 2015 at 12:39:24PM -0700, David Ahern escreveu:
> 
> 
> On 02/13/2015 11:40 AM, Suzuki K. Poulose wrote:
> >From: "Suzuki K. Poulose" 
> >
> >Commit 1971f59 (perf stat: Use read_counter in read_counter_aggr )
> >broke the perf stat output for unsupported counters.
> >
> >  $ perf stat -v -a -C 0 -e CCI_400/config=24/ sleep 1
> >  Warning:
> >  CCI_400/config=24/ event is not supported by the kernel.
> >
> >   Performance counter stats for 'system wide':
> >
> >   0  CCI_400/config=24/
> >
> > 1.080265400 seconds time elapsed
> >
> >Where it used to be :
> >
> >$ perf stat -v -a -C 0 -e CCI_400/config=24/ sleep 1
> >  Warning:
> >  CCI_400/config=24/ event is not supported by the kernel.
> >
> >   Performance counter stats for 'system wide':
> >
> >   CCI_400/config=24/
> >
> > 1.083840675 seconds time elapsed
> >
> >This patch fixes the issues by checking if the counter is supported,
> >before reading and logging the counter value.
> >
> >Cc: Jiri Olsa 
> >Cc: Arnaldo Carvalho de Melo 
> >Signed-off-by: Suzuki K. Poulose 
> >---
> >  tools/perf/builtin-stat.c |5 -
> >  1 file changed, 4 insertions(+), 1 deletion(-)
> >
> >diff --git a/tools/perf/builtin-stat.c b/tools/perf/builtin-stat.c
> >index e598e4e..d28949d 100644
> >--- a/tools/perf/builtin-stat.c
> >+++ b/tools/perf/builtin-stat.c
> >@@ -510,6 +510,9 @@ static int read_counter(struct perf_evsel *counter)
> > int ncpus = perf_evsel__nr_cpus(counter);
> > int cpu, thread;
> >
> >+if (!counter->supported)
> >+return -ENOENT;
> >+
> > if (counter->system_wide)
> > nthreads = 1;
> >
> >@@ -1285,7 +1288,7 @@ static void print_counter_aggr(struct perf_evsel 
> >*counter, char *prefix)
> > if (prefix)
> > fprintf(output, "%s", prefix);
> >
> >-if (scaled == -1) {
> >+if (scaled == -1 || !counter->supported) {
> > fprintf(output, "%*s%s",
> > csv_output ? 0 : 18,
> > counter->supported ? CNTR_NOT_COUNTED : 
> > CNTR_NOT_SUPPORTED,
> >
> 
> Just hit this as well.
> 
> Acked-and-Tested-by: David Ahern 

Gack, 10ms after I sent my pre-California pull req :-\

Will go in the next one :-)

- Arnaldo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 19/43] perf build: Add perf.o object building

[Arnaldo Carvalho de Melo]

From: Jiri Olsa 

Move the perf object building under build framework to be included in
the perf build object.

Signed-off-by: Jiri Olsa 
Tested-by: Sukadev Bhattiprolu 
Tested-by: Will Deacon 
Cc: Alexis Berlemont 
Cc: Borislav Petkov 
Cc: Corey Ashford 
Cc: David Ahern 
Cc: Frederic Weisbecker 
Cc: Namhyung Kim 
Cc: Paul Mackerras 
Cc: Peter Zijlstra 
Cc: Stephane Eranian 
Link: http://lkml.kernel.org/n/tip-wiiciip2w6ajvj03huqz5...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/Build |  3 +++
 tools/perf/Makefile.perf | 16 +---
 2 files changed, 8 insertions(+), 11 deletions(-)

diff --git a/tools/perf/Build b/tools/perf/Build
index 133ec649e5a2..976e03849f6d 100644
--- a/tools/perf/Build
+++ b/tools/perf/Build
@@ -25,12 +25,15 @@ perf-$(CONFIG_LIBELF) += builtin-probe.o
 perf-y += bench/
 perf-y += tests/
 
+perf-y += perf.o
+
 paths += -DPERF_HTML_PATH="BUILD_STR($(htmldir_SQ))"
 paths += -DPERF_INFO_PATH="BUILD_STR($(infodir_SQ))"
 paths += -DPERF_MAN_PATH="BUILD_STR($(mandir_SQ))"
 
 CFLAGS_builtin-help.o  += $(paths)
 CFLAGS_builtin-timechart.o += $(paths)
+CFLAGS_perf.o  += -DPERF_HTML_PATH="BUILD_STR($(htmldir_SQ))" 
-include $(OUTPUT)PERF-VERSION-FILE
 
 libperf-y += util/
 libperf-y += arch/
diff --git a/tools/perf/Makefile.perf b/tools/perf/Makefile.perf
index 713f4d17c553..0a669f990b68 100644
--- a/tools/perf/Makefile.perf
+++ b/tools/perf/Makefile.perf
@@ -376,16 +376,11 @@ PERF_IN := $(OUTPUT)perf-in.o
 export srctree OUTPUT RM CC LD AR CFLAGS V BISON FLEX
 build := -f $(srctree)/tools/build/Makefile.build dir=. obj
 
-$(PERF_IN): $(OUTPUT)common-cmds.h FORCE
+$(PERF_IN): $(OUTPUT)PERF-VERSION-FILE $(OUTPUT)common-cmds.h FORCE
@$(MAKE) $(build)=perf
 
-$(OUTPUT)perf.o: perf.c $(OUTPUT)common-cmds.h $(OUTPUT)PERF-CFLAGS
-   $(QUIET_CC)$(CC) -include $(OUTPUT)PERF-VERSION-FILE \
-   '-DPERF_HTML_PATH="$(htmldir_SQ)"' \
-   $(CFLAGS) -c $(filter %.c,$^) -o $@
-
-$(OUTPUT)perf: $(OUTPUT)perf.o $(BUILTIN_OBJS) $(PERFLIBS) $(PERF_IN)
-   $(QUIET_LINK)$(CC) $(CFLAGS) $(LDFLAGS) $(OUTPUT)perf.o \
+$(OUTPUT)perf: $(BUILTIN_OBJS) $(PERFLIBS) $(PERF_IN)
+   $(QUIET_LINK)$(CC) $(CFLAGS) $(LDFLAGS) \
$(BUILTIN_OBJS) $(PERF_IN) $(LIBS) -o $@
 
 $(GTK_IN): FORCE
@@ -403,8 +398,7 @@ $(SCRIPTS) : % : %.sh
$(QUIET_GEN)$(INSTALL) '$@.sh' '$(OUTPUT)$@'
 
 # These can record PERF_VERSION
-$(OUTPUT)perf.o perf.spec \
-   $(SCRIPTS) \
+perf.spec $(SCRIPTS) \
: $(OUTPUT)PERF-VERSION-FILE
 
 .SUFFIXES:
@@ -659,7 +653,7 @@ config-clean:
@$(MAKE) -C config/feature-checks clean >/dev/null
 
 clean: $(LIBTRACEEVENT)-clean $(LIBAPIKFS)-clean config-clean
-   $(call QUIET_CLEAN, core-objs)  $(RM) $(LIB_OBJS) $(BUILTIN_OBJS) 
$(LIB_FILE) $(OUTPUT)perf-archive $(OUTPUT)perf-with-kcore $(OUTPUT)perf.o 
$(LANG_BINDINGS)
+   $(call QUIET_CLEAN, core-objs)  $(RM) $(LIB_OBJS) $(BUILTIN_OBJS) 
$(LIB_FILE) $(OUTPUT)perf-archive $(OUTPUT)perf-with-kcore $(LANG_BINDINGS)
@find . -name '*.o' -delete -o -name '\.*.cmd' -delete -o -name '\.*.d' 
-delete
@$(RM) .config-detected
$(call QUIET_CLEAN, core-progs) $(RM) $(ALL_PROGRAMS) perf 
perf-read-vdso32 perf-read-vdsox32
-- 
1.9.3

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

[PATCH 18/43] perf build: Add zlib objects building

[Arnaldo Carvalho de Melo]

From: Jiri Olsa 

Move the zlib objects building under build framework to be included in
the libperf build object.

Signed-off-by: Jiri Olsa 
Tested-by: Sukadev Bhattiprolu 
Tested-by: Will Deacon 
Cc: Alexis Berlemont 
Cc: Borislav Petkov 
Cc: Corey Ashford 
Cc: David Ahern 
Cc: Frederic Weisbecker 
Cc: Namhyung Kim 
Cc: Paul Mackerras 
Cc: Peter Zijlstra 
Cc: Stephane Eranian 
Link: http://lkml.kernel.org/n/tip-cpbb47g82ahpa4yqfr9dc...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/Makefile.perf   | 4 
 tools/perf/config/Makefile | 1 +
 tools/perf/util/Build  | 1 +
 3 files changed, 2 insertions(+), 4 deletions(-)

diff --git a/tools/perf/Makefile.perf b/tools/perf/Makefile.perf
index 7daccaccd02f..713f4d17c553 100644
--- a/tools/perf/Makefile.perf
+++ b/tools/perf/Makefile.perf
@@ -349,10 +349,6 @@ install-gtk: $(OUTPUT)libperf-gtk.so
$(INSTALL) $(OUTPUT)libperf-gtk.so '$(DESTDIR_SQ)$(libdir_SQ)'
 endif
 
-ifndef NO_ZLIB
-  LIB_OBJS += $(OUTPUT)util/zlib.o
-endif
-
 ifdef ASCIIDOC8
   export ASCIIDOC8
 endif
diff --git a/tools/perf/config/Makefile b/tools/perf/config/Makefile
index 2fc4d5682c3b..b97a7b903a23 100644
--- a/tools/perf/config/Makefile
+++ b/tools/perf/config/Makefile
@@ -640,6 +640,7 @@ ifndef NO_ZLIB
   ifeq ($(feature-zlib), 1)
 CFLAGS += -DHAVE_ZLIB_SUPPORT
 EXTLIBS += -lz
+$(call detected,CONFIG_ZLIB)
   else
 NO_ZLIB := 1
   endif
diff --git a/tools/perf/util/Build b/tools/perf/util/Build
index f69843218228..459918872f07 100644
--- a/tools/perf/util/Build
+++ b/tools/perf/util/Build
@@ -91,6 +91,7 @@ libperf-$(CONFIG_LIBUNWIND)  += unwind-libunwind.o
 libperf-y += scripting-engines/
 
 libperf-$(CONFIG_PERF_REGS) += perf_regs.o
+libperf-$(CONFIG_ZLIB) += zlib.o
 
 CFLAGS_config.o   += -DETC_PERFCONFIG="BUILD_STR($(ETC_PERFCONFIG_SQ))"
 CFLAGS_exec_cmd.o += -DPERF_EXEC_PATH="BUILD_STR($(perfexecdir_SQ))" 
-DPREFIX="BUILD_STR($(prefix_SQ))"
-- 
1.9.3

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

[PATCH 23/43] perf build: Add arch powerpc objects building

[Arnaldo Carvalho de Melo]

From: Jiri Olsa 

Move the powerpc arch objects building under build framework to be
included in the libperf build object.

Signed-off-by: Jiri Olsa 
Tested-by: Sukadev Bhattiprolu 
Tested-by: Will Deacon 
Cc: Alexis Berlemont 
Cc: Borislav Petkov 
Cc: Corey Ashford 
Cc: David Ahern 
Cc: Frederic Weisbecker 
Cc: Namhyung Kim 
Cc: Paul Mackerras 
Cc: Peter Zijlstra 
Cc: Stephane Eranian 
Link: http://lkml.kernel.org/n/tip-nqrtlipvjptdyjfuzlneg...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/arch/powerpc/Build  | 1 +
 tools/perf/arch/powerpc/Makefile   | 3 ---
 tools/perf/arch/powerpc/util/Build | 4 
 3 files changed, 5 insertions(+), 3 deletions(-)
 create mode 100644 tools/perf/arch/powerpc/util/Build

diff --git a/tools/perf/arch/powerpc/Build b/tools/perf/arch/powerpc/Build
index e69de29bb2d1..54afe4a467e7 100644
--- a/tools/perf/arch/powerpc/Build
+++ b/tools/perf/arch/powerpc/Build
@@ -0,0 +1 @@
+libperf-y += util/
diff --git a/tools/perf/arch/powerpc/Makefile b/tools/perf/arch/powerpc/Makefile
index 6f7782bea5dd..7fbca175099e 100644
--- a/tools/perf/arch/powerpc/Makefile
+++ b/tools/perf/arch/powerpc/Makefile
@@ -1,6 +1,3 @@
 ifndef NO_DWARF
 PERF_HAVE_DWARF_REGS := 1
-LIB_OBJS += $(OUTPUT)arch/$(ARCH)/util/dwarf-regs.o
-LIB_OBJS += $(OUTPUT)arch/$(ARCH)/util/skip-callchain-idx.o
 endif
-LIB_OBJS += $(OUTPUT)arch/$(ARCH)/util/header.o
diff --git a/tools/perf/arch/powerpc/util/Build 
b/tools/perf/arch/powerpc/util/Build
new file mode 100644
index ..0af6e9b3f728
--- /dev/null
+++ b/tools/perf/arch/powerpc/util/Build
@@ -0,0 +1,4 @@
+libperf-y += header.o
+
+libperf-$(CONFIG_DWARF) += dwarf-regs.o
+libperf-$(CONFIG_DWARF) += skip-callchain-idx.o
-- 
1.9.3

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

[PATCH 24/43] perf build: Add arch s390 objects building

[Arnaldo Carvalho de Melo]

From: Jiri Olsa 

Move the s390 arch objects building under build framework to be included
in the libperf build object.

Signed-off-by: Jiri Olsa 
Tested-by: Sukadev Bhattiprolu 
Tested-by: Will Deacon 
Cc: Alexis Berlemont 
Cc: Borislav Petkov 
Cc: Corey Ashford 
Cc: David Ahern 
Cc: Frederic Weisbecker 
Cc: Namhyung Kim 
Cc: Paul Mackerras 
Cc: Peter Zijlstra 
Cc: Stephane Eranian 
Link: http://lkml.kernel.org/n/tip-8f5tlfwegkirhir2ffz8n...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/arch/s390/Build  | 1 +
 tools/perf/arch/s390/Makefile   | 3 ---
 tools/perf/arch/s390/util/Build | 4 
 3 files changed, 5 insertions(+), 3 deletions(-)
 create mode 100644 tools/perf/arch/s390/util/Build

diff --git a/tools/perf/arch/s390/Build b/tools/perf/arch/s390/Build
index e69de29bb2d1..54afe4a467e7 100644
--- a/tools/perf/arch/s390/Build
+++ b/tools/perf/arch/s390/Build
@@ -0,0 +1 @@
+libperf-y += util/
diff --git a/tools/perf/arch/s390/Makefile b/tools/perf/arch/s390/Makefile
index 798ac7379c5f..21322e0385b8 100644
--- a/tools/perf/arch/s390/Makefile
+++ b/tools/perf/arch/s390/Makefile
@@ -1,7 +1,4 @@
 ifndef NO_DWARF
 PERF_HAVE_DWARF_REGS := 1
-LIB_OBJS += $(OUTPUT)arch/$(ARCH)/util/dwarf-regs.o
 endif
-LIB_OBJS += $(OUTPUT)arch/$(ARCH)/util/header.o
 HAVE_KVM_STAT_SUPPORT := 1
-LIB_OBJS += $(OUTPUT)arch/$(ARCH)/util/kvm-stat.o
diff --git a/tools/perf/arch/s390/util/Build b/tools/perf/arch/s390/util/Build
new file mode 100644
index ..8a61372bb47a
--- /dev/null
+++ b/tools/perf/arch/s390/util/Build
@@ -0,0 +1,4 @@
+libperf-y += header.o
+libperf-y += kvm-stat.o
+
+libperf-$(CONFIG_DWARF) += dwarf-regs.o
-- 
1.9.3

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

[PATCH 27/43] perf build: Add single target build framework support

[Arnaldo Carvalho de Melo]

From: Jiri Olsa 

Add support to build single targets, like:

 $ make util/map.o# objects
 $ make util/map.i# preprocessor
 $ make util/map.s# assembly

Signed-off-by: Jiri Olsa 
Tested-by: Sukadev Bhattiprolu 
Tested-by: Will Deacon 
Cc: Alexis Berlemont 
Cc: Borislav Petkov 
Cc: Corey Ashford 
Cc: David Ahern 
Cc: Frederic Weisbecker 
Cc: Namhyung Kim 
Cc: Paul Mackerras 
Cc: Peter Zijlstra 
Cc: Stephane Eranian 
Link: http://lkml.kernel.org/n/tip-tt10y0dmweq6rjaod937r...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/build/Makefile.build | 20 +++-
 tools/perf/Makefile.perf   | 39 ---
 tools/perf/util/Build  |  8 
 3 files changed, 55 insertions(+), 12 deletions(-)

diff --git a/tools/build/Makefile.build b/tools/build/Makefile.build
index aced86d2bbf8..b5ded207f49b 100644
--- a/tools/build/Makefile.build
+++ b/tools/build/Makefile.build
@@ -49,6 +49,12 @@ quiet_cmd_mkdir = MKDIR$(dir $@)
 quiet_cmd_cc_o_c = CC   $@
   cmd_cc_o_c = $(CC) $(c_flags) -c -o $@ $<
 
+quiet_cmd_cc_i_c = CPP  $@
+  cmd_cc_i_c = $(CC) $(c_flags) -E -o $@ $<
+
+quiet_cmd_cc_s_c = AS   $@
+  cmd_cc_s_c = $(CC) $(c_flags) -S -o $@ $<
+
 # Link agregate command
 # If there's nothing to link, create empty $@ object.
 quiet_cmd_ld_multi = LD   $@
@@ -64,6 +70,18 @@ $(OUTPUT)%.o: %.S FORCE
$(call rule_mkdir)
$(call if_changed_dep,cc_o_c)
 
+$(OUTPUT)%.i: %.c FORCE
+   $(call rule_mkdir)
+   $(call if_changed_dep,cc_i_c)
+
+$(OUTPUT)%.i: %.S FORCE
+   $(call rule_mkdir)
+   $(call if_changed_dep,cc_i_c)
+
+$(OUTPUT)%.s: %.c FORCE
+   $(call rule_mkdir)
+   $(call if_changed_dep,cc_s_c)
+
 # Gather build data:
 #   obj-y- list of build objects
 #   subdir-y - list of directories to nest
@@ -100,7 +118,7 @@ FORCE:
 
 # Include all cmd files to get all the dependency rules
 # for all objects included
-targets   := $(wildcard $(sort $(obj-y) $(in-target)))
+targets   := $(wildcard $(sort $(obj-y) $(in-target) $(MAKECMDGOALS)))
 cmd_files := $(wildcard $(foreach f,$(targets),$(dir $(f)).$(notdir $(f)).cmd))
 
 ifneq ($(cmd_files),)
diff --git a/tools/perf/Makefile.perf b/tools/perf/Makefile.perf
index 0a669f990b68..ef637e99a2fa 100644
--- a/tools/perf/Makefile.perf
+++ b/tools/perf/Makefile.perf
@@ -421,16 +421,33 @@ endif
 # These two need to be here so that when O= is not used they take precedence
 # over the general rule for .o
 
-$(OUTPUT)%.o: %.c $(OUTPUT)PERF-CFLAGS
-   $(QUIET_CC)$(CC) -o $@ -c $(CFLAGS) $<
-$(OUTPUT)%.i: %.c $(OUTPUT)PERF-CFLAGS
-   $(QUIET_CC)$(CC) -o $@ -E $(CFLAGS) $<
-$(OUTPUT)%.s: %.c $(OUTPUT)PERF-CFLAGS
-   $(QUIET_CC)$(CC) -o $@ -S $(CFLAGS) $<
-$(OUTPUT)%.o: %.S
-   $(QUIET_CC)$(CC) -o $@ -c $(CFLAGS) $<
-$(OUTPUT)%.s: %.S
-   $(QUIET_CC)$(CC) -o $@ -E $(CFLAGS) $<
+# get relative building directory (to $(OUTPUT))
+# and '.' if it's $(OUTPUT) itself
+__build-dir = $(subst $(OUTPUT),,$(dir $@))
+build-dir   = $(if $(__build-dir),$(__build-dir),.)
+
+single_dep: $(OUTPUT)PERF-VERSION-FILE $(OUTPUT)common-cmds.h
+
+$(OUTPUT)%.o: %.c single_dep FORCE
+   @$(MAKE) -f $(srctree)/tools/build/Makefile.build dir=$(build-dir) $@
+
+$(OUTPUT)%.i: %.c single_dep FORCE
+   @$(MAKE) -f $(srctree)/tools/build/Makefile.build dir=$(build-dir) $@
+
+$(OUTPUT)%.s: %.c single_dep FORCE
+   @$(MAKE) -f $(srctree)/tools/build/Makefile.build dir=$(build-dir) $@
+
+$(OUTPUT)%-bison.o: %.c single_dep FORCE
+   @$(MAKE) -f $(srctree)/tools/build/Makefile.build dir=$(build-dir) $@
+
+$(OUTPUT)%-flex.o: %.c single_dep FORCE
+   @$(MAKE) -f $(srctree)/tools/build/Makefile.build dir=$(build-dir) $@
+
+$(OUTPUT)%.o: %.S single_dep FORCE
+   @$(MAKE) -f $(srctree)/tools/build/Makefile.build dir=$(build-dir) $@
+
+$(OUTPUT)%.i: %.S single_dep FORCE
+   @$(MAKE) -f $(srctree)/tools/build/Makefile.build dir=$(build-dir) $@
 
 $(OUTPUT)perf-%: %.o $(PERFLIBS)
$(QUIET_LINK)$(CC) $(CFLAGS) -o $@ $(LDFLAGS) $(filter %.o,$^) $(LIBS)
@@ -675,5 +692,5 @@ FORCE:
 
 .PHONY: all install clean config-clean strip install-gtk
 .PHONY: shell_compatibility_test please_set_SHELL_PATH_to_a_more_modern_shell
-.PHONY: $(GIT-HEAD-PHONY) TAGS tags cscope .FORCE-PERF-CFLAGS FORCE
+.PHONY: $(GIT-HEAD-PHONY) TAGS tags cscope .FORCE-PERF-CFLAGS FORCE single_dep
 
diff --git a/tools/perf/util/Build b/tools/perf/util/Build
index 459918872f07..32f9327b1a97 100644
--- a/tools/perf/util/Build
+++ b/tools/perf/util/Build
@@ -97,15 +97,19 @@ CFLAGS_config.o   += 
-DETC_PERFCONFIG="BUILD_STR($(ETC_PERFCONFIG_SQ))"
 CFLAGS_exec_cmd.o += -DPERF_EXEC_PATH="BUILD_STR($(perfexecdir_SQ))" 
-DPREFIX="BUILD_STR($(prefix_SQ))"
 
 $(OUTPUT)util/parse-events-flex.c: util/parse-events.l 
$(OUTPUT)util/parse-events-bison.c
+   $(call rule_mkdir)
@$(call echo-cmd,flex)$(FLEX) -o $@ 
--header-file=$(OUTPUT)util/parse-events-flex.h 

[PATCH 30/43] perf build: Remove PERF-CFLAGS file

[Arnaldo Carvalho de Melo]

From: Jiri Olsa 

Removing PERF-CFLAGS file, because the build framework stores full build
command line for each object and triggers rebuilt if necessary.

Signed-off-by: Jiri Olsa 
Tested-by: Sukadev Bhattiprolu 
Tested-by: Will Deacon 
Cc: Alexis Berlemont 
Cc: Borislav Petkov 
Cc: Corey Ashford 
Cc: David Ahern 
Cc: Frederic Weisbecker 
Cc: Namhyung Kim 
Cc: Paul Mackerras 
Cc: Peter Zijlstra 
Cc: Stephane Eranian 
Link: http://lkml.kernel.org/n/tip-99hamnd2msiwgsi78yaui...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/Makefile.perf | 17 +++--
 1 file changed, 3 insertions(+), 14 deletions(-)

diff --git a/tools/perf/Makefile.perf b/tools/perf/Makefile.perf
index d49f7930d544..710731b4268e 100644
--- a/tools/perf/Makefile.perf
+++ b/tools/perf/Makefile.perf
@@ -365,7 +365,7 @@ LIBTRACEEVENT_FLAGS  = $(QUIET_SUBDIR1) O=$(OUTPUT)
 LIBTRACEEVENT_FLAGS += CFLAGS="-g -Wall $(EXTRA_CFLAGS)"
 LIBTRACEEVENT_FLAGS += plugin_dir=$(plugindir_SQ)
 
-$(LIBTRACEEVENT): $(TE_SOURCES) $(OUTPUT)PERF-CFLAGS
+$(LIBTRACEEVENT): $(TE_SOURCES)
$(QUIET_SUBDIR0)$(TRACE_EVENT_DIR) $(LIBTRACEEVENT_FLAGS) 
libtraceevent.a plugins
 
 $(LIBTRACEEVENT)-clean:
@@ -444,17 +444,6 @@ cscope:
$(QUIET_GEN)$(RM) cscope*; \
$(FIND) $(TAG_FOLDERS) -name '*.[hcS]' -print | xargs cscope -b 
$(TAG_FILES)
 
-### Detect prefix changes
-TRACK_CFLAGS = $(subst ','\'',$(CFLAGS)):\
- 
$(bindir_SQ):$(perfexecdir_SQ):$(template_dir_SQ):$(prefix_SQ):$(plugindir_SQ)
-
-$(OUTPUT)PERF-CFLAGS: .FORCE-PERF-CFLAGS
-   @FLAGS='$(TRACK_CFLAGS)'; \
-   if test x"$$FLAGS" != x"`cat $(OUTPUT)PERF-CFLAGS 2>/dev/null`" ; 
then \
-   echo 1>&2 "  FLAGS:   * new build flags or prefix"; \
-   echo "$$FLAGS" >$(OUTPUT)PERF-CFLAGS; \
-fi
-
 ### Testing rules
 
 # GNU make supports exporting all variables by "export" without parameters.
@@ -544,7 +533,7 @@ clean: $(LIBTRACEEVENT)-clean $(LIBAPIKFS)-clean 
config-clean
@find . -name '*.o' -delete -o -name '\.*.cmd' -delete -o -name '\.*.d' 
-delete
@$(RM) .config-detected
$(call QUIET_CLEAN, core-progs) $(RM) $(ALL_PROGRAMS) perf 
perf-read-vdso32 perf-read-vdsox32
-   $(call QUIET_CLEAN, core-gen)   $(RM)  *.spec *.pyc *.pyo */*.pyc 
*/*.pyo $(OUTPUT)common-cmds.h TAGS tags cscope* $(OUTPUT)PERF-VERSION-FILE 
$(OUTPUT)PERF-CFLAGS $(OUTPUT)PERF-FEATURES $(OUTPUT)util/*-bison* 
$(OUTPUT)util/*-flex*
+   $(call QUIET_CLEAN, core-gen)   $(RM)  *.spec *.pyc *.pyo */*.pyc 
*/*.pyo $(OUTPUT)common-cmds.h TAGS tags cscope* $(OUTPUT)PERF-VERSION-FILE 
$(OUTPUT)PERF-FEATURES $(OUTPUT)util/*-bison* $(OUTPUT)util/*-flex*
$(QUIET_SUBDIR0)Documentation $(QUIET_SUBDIR1) clean
$(python-clean)
 
@@ -562,5 +551,5 @@ FORCE:
 
 .PHONY: all install clean config-clean strip install-gtk
 .PHONY: shell_compatibility_test please_set_SHELL_PATH_to_a_more_modern_shell
-.PHONY: $(GIT-HEAD-PHONY) TAGS tags cscope .FORCE-PERF-CFLAGS FORCE single_dep
+.PHONY: $(GIT-HEAD-PHONY) TAGS tags cscope FORCE single_dep
 
-- 
1.9.3

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