linux.kernel - 26 new messages in 16 topics - digest

linux.kernel
http://groups.google.com/group/linux.kernel?hl=en

linux.kernel@googlegroups.com

Today's topics:

* spi: add Intel Mid SSP driver - 3 messages, 3 authors
http://groups.google.com/group/linux.kernel/t/ef605b1453b60008?hl=en
* ata: libata-eh: Remove unnecessary snprintf arithmetic - 2 messages, 2
authors
http://groups.google.com/group/linux.kernel/t/15331602c8e843a1?hl=en
* hung_task debugging: Add tracepoint to report the hang - 1 messages, 1
author
http://groups.google.com/group/linux.kernel/t/ca7f8d3201879a8c?hl=en
* ARM: Support arch_irq_work_raise() via self IPIs - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/9ee5fac709d8de4a?hl=en
* ARM: msm: Remove 7x00 support - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/6a4ce799f2cf2588?hl=en
* spmi: Linux driver framework for SPMI - 2 messages, 1 author
http://groups.google.com/group/linux.kernel/t/089572c2f7d04979?hl=en
* dma: mv_xor: Use high_base mmio where appropriate - 2 messages, 2 authors
http://groups.google.com/group/linux.kernel/t/6b8943051cef24d1?hl=en
* KVM: Fix modprobe failure for kvm_intel/kvm_amd - 2 messages, 2 authors
http://groups.google.com/group/linux.kernel/t/c37bef49a3050c22?hl=en
* kernel: use lockless list for smp_call_function_single - 2 messages, 2
authors
http://groups.google.com/group/linux.kernel/t/6e0e06d759089a1f?hl=en
* Subject: [v3.8][v3.11][Regression] [SCSI] sd: Update WRITE SAME heuristics -
4 messages, 3 authors
http://groups.google.com/group/linux.kernel/t/5bf81d6615c1244f?hl=en
* perf events ring buffer memory barrier on powerpc - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/d7e2f84d9477fb85?hl=en
* ARM seccomp filters and EABI/OABI - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/53f42e90df679dd4?hl=en
* Move drivers/acpi/apei/cper.c to drivers/firmware/efi/ - 1 messages, 1
author
http://groups.google.com/group/linux.kernel/t/fed644237d7ddfa7?hl=en
* Revert 9745cdb36da83aeec198650b410ca06304cf792 ("select: use freezable
blocking call")? - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/d5781c359b092c6c?hl=en
* Support for perf to probe into SDT markers: - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/03ad07929773e148?hl=en
* clk: Implement clk_unregister() - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/8b342eba360d1672?hl=en

==============================================================================
TOPIC: spi: add Intel Mid SSP driver
http://groups.google.com/group/linux.kernel/t/ef605b1453b60008?hl=en
==============================================================================

== 1 of 3 ==
Date: Tues, Oct 29 2013 12:00 pm
From: Mark Brown



On Tue, Oct 29, 2013 at 11:05:49AM -0700, David Cohen wrote:
> From: Fei Yang <fei.yang@intel.com>
>
> This patch adds driver for ssp spi interface on Intel Mid platform.

Is there not any possibility of code sharing with the PXA SSP IP? It
seems odd that Intel would make a second IP of the same name that's
totally incompatible... not looked at the register interfaces in detail
but the register names certainly look familiar.

> + tristate "SSP SPI controller driver for Intel MID platforms (EXPERIMENTAL)"
> + depends on X86_INTEL_MID && SPI_MASTER && INTEL_MID_DMAC
> + help

Are these all build time dependencies? There's certainly no need to
depend on SPI_MASTER, all drivers are inside an if SPI_MASTER block.

> +static int ssp_timing_wr;

Why is this a static global?

> +#ifdef DUMP_RX
> +static void dump_trailer(const struct device *dev, char *buf, int len, int sz)
> +{

Please add this support as a standard feature of the SPI core if it's
useful, there's nothing specific to this driver in it. Using trace
would probably be better than dumping to the console.

> + static char msg[MAX_SPI_TRANSFER_SIZE];

Where did that limit come from?

> +static inline u32 is_tx_fifo_empty(struct ssp_drv_context *sspc)
> +{
> + u32 sssr;
> + sssr = read_SSSR(sspc->ioaddr);
> + if ((sssr & SSSR_TFL_MASK) || (sssr & SSSR_TNF) == 0)

This looks odd, why not sssr & (SSSR_TFL_MASK | SSSR_TNF)?

> +static void flush(struct ssp_drv_context *sspc)
> +{
> + void *reg = sspc->ioaddr;
> + u32 i = 0;
> +
> + /* If the transmit fifo is not empty, reset the interface. */
> + if (!is_tx_fifo_empty(sspc)) {
> + dev_err(&sspc->pdev->dev, "TX FIFO not empty. Reset of SPI IF");
> + disable_interface(sspc);
> + return;
> + }

This isn't a flush then?

> + dev_dbg(&sspc->pdev->dev, " SSSR=%x\r\n", read_SSSR(reg));

No extra space at the start of the message and why is there a \r in
there? Throughout the driver your log messages have a range of odd
formatting quirks that aren't consistent and don't look like normal
Linux log messages either.

Please also check the severity of your messages, many of them seem too
loud.

> + while (!is_rx_fifo_empty(sspc) && (i < SPI_FIFO_SIZE + 1)) {
> + read_SSDR(reg);
> + i++;
> + }

What happens if the FIFO doesn't drain?

> + WARN(i > 0, "%d words flush occured\n", i);

This seems *very* loud for a flush operation...

> + if (sspc->quirks & QUIRKS_SRAM_ADDITIONAL_CPY) {
> + sspc->virt_addr_sram_rx = ioremap_nocache(SRAM_BASE_ADDR,
> + 2 * MAX_SPI_TRANSFER_SIZE);

This doesn't look terribly clever, it's remapping a hard coded address
rather than getting the address enumerated from a device enumeration
interface.

> + /* get Data Read/Write address */
> + ssdr_addr = (dma_addr_t)(sspc->paddr + 0x10);

I'm not entirely sure what this does but it looks dodgy... what's the
cast doing for a start?

> + /* In Rx direction, TRAIL Bytes are handled by memcpy */

Please don't randomly CAPITALISE words.

> + rxdesc = rxchan->device->device_prep_dma_memcpy
> + (rxchan, /* DMA Channel */
> + sspc->rx_dma, /* DAR */
> + ssdr_addr, /* SAR */
> + sspc->len_dma_rx, /* Data Length */
> + flag); /* Flag */

What's going on here? Why is there a DMAed memcpy()? This doesn't
reflect normal DMA usage in SPI drivers at all, I'd expect to see
dmaengine_prep_ being used.

> +static void int_transfer_complete(struct ssp_drv_context *sspc)
> +{
> + void *reg = sspc->ioaddr;
> + struct spi_message *msg;
> + struct device *dev = &sspc->pdev->dev;
> +
> + if (unlikely(sspc->quirks & QUIRKS_USE_PM_QOS))
> + pm_qos_update_request(&sspc->pm_qos_req,
> + PM_QOS_DEFAULT_VALUE);

Why is this a quirk and not abstracted away by the PM QoS API on
platforms that don't need it? I'd also expect these updates to be done
in runtime PM callbacks so that if two transfers follow one another we
don't bounce the Qos up and down.

> + dev_dbg(dev, "End of transfer. SSSR:%08X\n", read_SSSR(reg));
> + msg = sspc->cur_msg;
> + if (likely(msg->complete))
> + msg->complete(msg->context);
> + complete(&sspc->msg_done);

Remove all these likely()s, they're making the code less clear and seem
vanishingly unlikely to have any practical impact on performance.

> +static void int_transfer_complete_work(struct work_struct *work)
> +{
> + struct ssp_drv_context *sspc = container_of(work,
> + struct ssp_drv_context, complete_work);
> +
> + int_transfer_complete(sspc);
> +}

This wrapper function doesn't seem terribly useful... why not just
inline it into the internal function?

> + if (status & SSSR_ROR || status & SSSR_TUR) {
> + dev_err(dev, "--- SPI ROR or TUR occurred : SSSR=%x\n", status);
> + WARN_ON(1);
> + if (status & SSSR_ROR)
> + dev_err(dev, "we have Overrun\n");
> + if (status & SSSR_TUR)
> + dev_err(dev, "we have Underrun\n");
> + }
> +
> + /* We can fall here when not using DMA mode */
> + if (!sspc->cur_msg) {
> + disable_interface(sspc);
> + disable_triggers(sspc);
> + }
> + /* clear status register */
> + write_SSSR(sspc->clear_sr, reg);

More comments explaining what's going on here would be good...

> +static void poll_transfer(unsigned long data)
> +{
> + struct ssp_drv_context *sspc = (void *)data;
> +
> + if (sspc->tx) {
> + while (sspc->tx != sspc->tx_end) {
> + if (ssp_timing_wr) {
> + int timeout = 100;
> + /* It is used as debug UART on Tangier. Since
> + baud rate = 115200, it needs at least 312us
> + for one word transferring. Becuase of silicon
> + issue, it MUST check SFIFOL here instead of
> + TNF. It is the workaround for A0 stepping*/
> + while (--timeout &&
> + ((read_SFIFOL(sspc->ioaddr)) & 0xFFFF))
> + udelay(10);
> + }

This doesn't look like it shouldn't be here at all or should be made
more generic but I can't really tell what it's supposed to do...

> +static void start_bitbanging(struct ssp_drv_context *sspc)
> +{

The SPI core has bitbanging helpers which you don't seem to be using.
However...

> + /* Bit bang the clock until CSS clears */
> + while ((sssr & 0x400000) && (count < MAX_BITBANGING_LOOP)) {
> + write_I2CDATA(0x2, i2c_reg);
> + udelay(I2C_ACCESS_USDELAY);

...this code is talking about I2C?

> + udelay(I2C_ACCESS_USDELAY);
> + write_I2CCTRL(0x01070034, i2c_reg);

This appears to be randomly bashing on an absolute register address.

> +/**
> + * transfer() - Start a SPI transfer
> + * @spi: Pointer to the spi_device struct
> + * @msg: Pointer to the spi_message struct
> + */
> +static int transfer(struct spi_device *spi, struct spi_message *msg)

Use of plain transfer() has been deprecated since v3.4, you should at
least be using transfer_one_message(). I've stopped reviewing at this
point since a lot of the rest of the code is replicating stuff that's in
the SPI core and will go away when you update to use the current APIs.




== 2 of 3 ==
Date: Tues, Oct 29 2013 12:30 pm
From: David Cohen


On 10/29/2013 11:35 AM, Joe Perches wrote:
> On Tue, 2013-10-29 at 11:30 -0700, David Cohen wrote:
>> Hi Joe,
>>
>> On 10/29/2013 11:19 AM, Joe Perches wrote:
>>> On Tue, 2013-10-29 at 11:05 -0700, David Cohen wrote:
>>>> This patch adds driver for ssp spi interface on Intel Mid platform.
>>>
>>> A few simple notes:
>>>
>>> Please consider using checkpatch.
>>
>> I did and got no warnings. But haven't used --strict option.
>
> Interesting. I thought there was a return (foo);
> statement that should have been marked, but I didn't
> actually run checkpatch.

It seems odd checkpatch didn't catch it. I'll investigate.

>
> static inline u32 is_rx_fifo_empty(struct ssp_drv_context *sspc)
> +{
> + return ((read_SSSR(sspc->ioaddr) & SSSR_RNE) == 0);
> +}
>
> This could be bool too

u32 seems unusual, but I'd prefer 'int' if it's fine for you.

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




== 3 of 3 ==
Date: Tues, Oct 29 2013 12:40 pm
From: Joe Perches


On Tue, 2013-10-29 at 12:32 -0700, David Cohen wrote:
> On 10/29/2013 11:35 AM, Joe Perches wrote:
> > On Tue, 2013-10-29 at 11:30 -0700, David Cohen wrote:
> >> On 10/29/2013 11:19 AM, Joe Perches wrote:
> >>> On Tue, 2013-10-29 at 11:05 -0700, David Cohen wrote:
> >>>> This patch adds driver for ssp spi interface on Intel Mid platform.
> >>> A few simple notes:
> >>> Please consider using checkpatch.
> >> I did and got no warnings. But haven't used --strict option.
> > Interesting. I thought there was a return (foo);
> > statement that should have been marked, but I didn't
> > actually run checkpatch.
>
> It seems odd checkpatch didn't catch it. I'll investigate.

No need. I believe I know why.
checkpatch doesn't use "$balanced_parens" checks for return
tests. I'm not sure it's worth fixing right now, but it
could be tested as:

if ($^V && $^V ge 5.10.0 &&
$stat =~ /^.\s*return\s*$balanced_parens\s*;\s*$/)

> > static inline u32 is_rx_fifo_empty(struct ssp_drv_context *sspc)
> > +{
> > + return ((read_SSSR(sspc->ioaddr) & SSSR_RNE) == 0);
> > +}
> > This could be bool too
> u32 seems unusual, but I'd prefer 'int' if it's fine for you.

Anything is_<foo> that returns what seems to be true/false
I think could be bool.

But, no worries, it's your code. Do what you think best.


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





==============================================================================
TOPIC: ata: libata-eh: Remove unnecessary snprintf arithmetic
http://groups.google.com/group/linux.kernel/t/15331602c8e843a1?hl=en
==============================================================================

== 1 of 2 ==
Date: Tues, Oct 29 2013 12:10 pm
From: Levente Kurusa


Remove an unnecessary arithmetic operation from a call to snprintf, because
the size parameter of snprintf includes the trailing null space.
Also, initialize the buffer on definition instead of a memset call.

Signed-off-by: Levente Kurusa <levex@linux.com>
---
diff --git a/drivers/ata/libata-eh.c b/drivers/ata/libata-eh.c
index f9476fb..b7c4146 100644
--- a/drivers/ata/libata-eh.c
+++ b/drivers/ata/libata-eh.c
@@ -2394,7 +2399,7 @@ static void ata_eh_link_report(struct ata_link *link)
struct ata_port *ap = link->ap;
struct ata_eh_context *ehc = &link->eh_context;
const char *frozen, *desc;
- char tries_buf[6];
+ char tries_buf[6] = "";
int tag, nr_failed = 0;

if (ehc->i.flags & ATA_EHI_QUIET)
@@ -2425,9 +2432,8 @@ static void ata_eh_link_report(struct ata_link *link)
if (ap->pflags & ATA_PFLAG_FROZEN)
frozen = " frozen";

- memset(tries_buf, 0, sizeof(tries_buf));
if (ap->eh_tries < ATA_EH_MAX_TRIES)
- snprintf(tries_buf, sizeof(tries_buf) - 1, " t%d",
+ snprintf(tries_buf, sizeof(tries_buf), " t%d",
ap->eh_tries);

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




== 2 of 2 ==
Date: Tues, Oct 29 2013 12:20 pm
From: Tejun Heo


On Tue, Oct 29, 2013 at 08:01:46PM +0100, Levente Kurusa wrote:
> Remove an unnecessary arithmetic operation from a call to snprintf, because
> the size parameter of snprintf includes the trailing null space.
> Also, initialize the buffer on definition instead of a memset call.
>
> Signed-off-by: Levente Kurusa <levex@linux.com>

Applied to libata/for-3.13.

Thanks.

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





==============================================================================
TOPIC: hung_task debugging: Add tracepoint to report the hang
http://groups.google.com/group/linux.kernel/t/ca7f8d3201879a8c?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Oct 29 2013 12:10 pm
From: Oleg Nesterov


On 10/20, Ingo Molnar wrote:
>
> * Oleg Nesterov <oleg@redhat.com> wrote:
>
> > Currently check_hung_task() prints a warning if it detects the problem,
> > but it is not convenient to watch the system logs if user-space wants to
> > be notified about the hang.
> >
> > Add the new trace_sched_process_hang() into check_hung_task(), this way
> > a user-space monitor can easily wait for the hang and potentially
> > resolve a problem.
>
> I'm wondering, is the data of trace_console() in kernel/printk/printk.c
> not sufficient?

Probably yes... I do not think they disable CONFIG_PRINTK.

But this is obviously much less convenient, they will need to parse the
text. And the user-space watchdog will be woken up much more often than
necessary. And they could probably simply read /var/log or interact with
syslogd somehow, but they specially asked for something better and more
robust.

But of course, I understand that every tracepoint should be justified.
So if you do not like this change I try to convince them to use
trace_console().

> If it's not enough then it might be better to add a higher level printk
> tracepoint instead - that can catch hung_task messages and (much) more.

Not sure I understand... I mean I do not understand why this is really
better for them, except this will simplify the parsing a bit. Anyway
I'd prefer to not send another doubtful patch ;)

Thanks.

Oleg.

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





==============================================================================
TOPIC: ARM: Support arch_irq_work_raise() via self IPIs
http://groups.google.com/group/linux.kernel/t/9ee5fac709d8de4a?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Oct 29 2013 12:10 pm
From: Kevin Hilman


Stephen Boyd <sboyd@codeaurora.org> writes:

> On 10/28, Kevin Hilman wrote:
>> Stephen Boyd <sboyd@codeaurora.org> writes:
>>
>> > This will allow the scheduler tick to be restarted if we're in
>> > full NOHZ mode.
>> >
>> > Cc: Kevin Hilman <khilman@linaro.org>
>> > Cc: Frederic Weisbecker <fweisbec@gmail.com>
>> > Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
>>
>> Minor nit, but I'd prefer a more verbose changelog (I forget things
>> quickly and like to rely on changelogs for my memory.) Probably worth
>> adding something like: "By default, irq_work is tied to the tick
>> processing (update_process_times()) but in full NOHZ mode, no tick means
>> no IRQ work. In order for IRQ work to be done in full NOHZ mode, a
>> self-IPI is used to process IRQ work."
>>
>> Other than the changelog nit, patch looks good, feel free to add
>>
>> Reviewed-by: Kevin Hilman <khilman@linaro.org>
>>
>> If Russell is OK with this, it can go to his patch system.
>>
>
> Fair enough. This is what I came up with. I'll send it off to the
> patch tracker in about 12 hours if nobody else has anymore
> comments.

Nice description, thanks for the respin.

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





==============================================================================
TOPIC: ARM: msm: Remove 7x00 support
http://groups.google.com/group/linux.kernel/t/6a4ce799f2cf2588?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Oct 29 2013 12:10 pm
From: Daniel Walker


On Tue, Oct 29, 2013 at 10:39:45AM -0700, Olof Johansson wrote:
> On Tue, Oct 29, 2013 at 10:08 AM, Daniel Walker <dwalker@fifo99.com> wrote:
>
> > Personally I think splitting mach- stuff isn't very useful or
> > interesting.. There's just no technical reason for it, for example x86
> > and x86_64 was a win from my perspective , there's a lot more reason to
> > keep similar things together than to split things up.
>
> There are definitely valid technical reasons for it; the old and new
> platforms share no code, and the legacy platforms are unlikely to be
> updated to modern infrastructure anytime soon. Other platforms are
> managed in similar manners, such as OMAP, imx/mxs, etc.

Are you speaking from a meta perspective , or you have specific example
in msm code ?


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





==============================================================================
TOPIC: spmi: Linux driver framework for SPMI
http://groups.google.com/group/linux.kernel/t/089572c2f7d04979?hl=en
==============================================================================

== 1 of 2 ==
Date: Tues, Oct 29 2013 12:20 pm
From: Lars-Peter Clausen


On 10/29/2013 05:30 PM, Stephen Boyd wrote:
> On 10/29/13 08:56, Josh Cartwright wrote:
>>
>>>> +#define to_spmi_controller(d) container_of(d, struct spmi_controller, dev)
>>> Should be a inline function for better type safety.
>> Sounds good. Will change the to_spmi_*() macros.
>
> I was under the impression that container_of() already does type
> checking. At least it will ensure that typeof(d) == typeof(dev) in the
> above example which is about as good as it can get.

Well you'll get a warning, but the quality of the warning message is much
better when an inline function is used.

warning: initialization from incompatible pointer type

vs.

warning: Passing argument 1 of to_smpi_controller() from incompatible
pointer type. Expected struct device * got struct driver *


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




== 2 of 2 ==
Date: Tues, Oct 29 2013 12:30 pm
From: Lars-Peter Clausen


On 10/29/2013 04:56 PM, Josh Cartwright wrote:
>>> +{
>>> + int dummy;
>>> +
>>> + if (!ctrl)
>>> + return -EINVAL;
>>> +
>>> + dummy = device_for_each_child(&ctrl->dev, NULL,
>>> + spmi_ctrl_remove_device);
>>> + device_unregister(&ctrl->dev);
>>
>> Should be device_del(). device_unregister() will do both device_del() and
>> put_device(). But usually you'd want to do something in between like release
>> resources used by the controller.
>
> I'm not sure I understand your suggestion here. If put_device() isn't
> called here, wouldn't we be leaking the controller? What resources
> would I want to be releasing here that aren't released as part of the
> controller's release() function?
>

Resources used by the driver implementing the controller. Usually the driver
state struct will be allocated by spmi_controller_alloc() as well. So if you
store resources in that struct, e.g. a clk you first want to unregister the
spmi controller to make sure that the resources are no longer accessed, then
free the resources and finally drop the reference to the controller so the
memory can be freed. E.g.

static int foobar_remove(struct platform_device *pdev)
{
struct spmi_controller *ctrl = platform_get_drvdata(pdev);
struct foobar *foobar = spmi_controller_get_drvdata(ctrl);

spmi_controller_remove(ctrl);

free_irq(foobar->irq)
clk_put(foobar->clk);
...

spmi_controller_put(ctrl);

return 0;
}

>>> + return 0;
>>> +}
>>> +EXPORT_SYMBOL_GPL(spmi_controller_remove);
>>> +
>> [...]
>>> +/**
>>> + * spmi_controller_alloc: Allocate a new SPMI controller
>>> + * @ctrl: associated controller
>>> + *
>>> + * Caller is responsible for either calling spmi_device_add() to add the
>>> + * newly allocated controller, or calling spmi_device_put() to discard it.
>>> + */
>>> +struct spmi_device *spmi_device_alloc(struct spmi_controller *ctrl);
>>> +
>>> +static inline void spmi_device_put(struct spmi_device *sdev)
>>
>> For symmetry reasons it might make sense to call this spmi_device_free().
>
> Except that it doesn't necessarily free() the underlying device, so I
> find that more confusing.

Well, for all the driver cares the device has been freed.

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





==============================================================================
TOPIC: dma: mv_xor: Use high_base mmio where appropriate
http://groups.google.com/group/linux.kernel/t/6b8943051cef24d1?hl=en
==============================================================================

== 1 of 2 ==
Date: Tues, Oct 29 2013 12:20 pm
From: Dan Williams


On Tue, Oct 29, 2013 at 2:32 AM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Dan, Ezequiel,
>
> On Tue, 29 Oct 2013 05:34:08 -0300, Ezequiel Garcia wrote:
>
>> > On Mon, Oct 28, 2013 at 3:54 PM, Ezequiel Garcia
>> > <ezequiel.garcia@free-electrons.com> wrote:
>> > > Despite requesting two memory resources, called 'base' and 'high_base', the
>> > > driver uses explicitly only the former. The latter is being used implicitly
>> > > by addressing at offset +0x200, which in practice accesses high_base.
>> > >
>> > > Instead of relying in such trick, let's define the registers with the
>> > > offset from high_base, and use high_base explicitly where appropriate.
>> > >
>> > > Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
>> > > ---
>> > > drivers/dma/mv_xor.c | 3 ++-
>> > > drivers/dma/mv_xor.h | 25 +++++++++++++------------
>> > > 2 files changed, 15 insertions(+), 13 deletions(-)
>> >
>> > Since it's unused I'd prefer a patch that just deletes xor_high_base.
>> >
>>
>> It's wrongly *unused*, the mmio high_base is actually being used
>> implicitly by always addressing at an offset that addresses +200.
>>
>> Deleting high_base would actually make it worse, for that region
>> will no longer be ioremaped. Maybe the commit message is not clear
>> about it?
>
> I agree with Ezequiel, and I believe his patch is appropriate. The
> registers for the XOR engines are indeed split in two areas, so it
> makes sense to have this xor_base / xor_high_base split that reflects
> the register mapping passed from the Device Tree, and use this split in
> the macros used to access the registers.
>

Ah ok, so it's a bug if an implementation ever puts the second
resource window at a non 0x200 offset.

Ezequiel , can you resend the patch to the new
dmaengine@vger.kernel.org list (patchwork queue) and clarify that this
is a fix rather than a pure cleanup in the changelog? At least
cleanup is how I first read it.

Thanks for the clarification.

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




== 2 of 2 ==
Date: Tues, Oct 29 2013 12:30 pm
From: Thomas Petazzoni


Dear Dan Williams,

On Tue, 29 Oct 2013 12:15:18 -0700, Dan Williams wrote:

> > I agree with Ezequiel, and I believe his patch is appropriate. The
> > registers for the XOR engines are indeed split in two areas, so it
> > makes sense to have this xor_base / xor_high_base split that reflects
> > the register mapping passed from the Device Tree, and use this split in
> > the macros used to access the registers.
> >
>
> Ah ok, so it's a bug if an implementation ever puts the second
> resource window at a non 0x200 offset.

Exactly.

Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/





==============================================================================
TOPIC: KVM: Fix modprobe failure for kvm_intel/kvm_amd
http://groups.google.com/group/linux.kernel/t/c37bef49a3050c22?hl=en
==============================================================================

== 1 of 2 ==
Date: Tues, Oct 29 2013 12:30 pm
From: Raghavendra K T


Adding Greg/AI too since we touch debugfs code.
[...]
>>
>> sudo modprobe kvm_amd
>> modprobe: ERROR: could not insert 'kvm_amd': Bad address
>
> "Bad address"? Christ people, are you guys making up error numbers
> with some kind of dice-roll? I can just see it now, somebody sitting
> there with a D20, playing some kind of kernel-specific D&D, and
> rolling a ten means that you get to slay the orc, and pick an error
> number of EFAULT for some random kernel function. Because quite
> frankly, "random dice roll" is the _only_ thing that explains "Bad
> address" sufficiently.
>
> Please, whoever wrote virt/kvm/kvm_main.c:: kvm_init_debug(), WTF?
> EFAULT means "user passed in an invalid virtual address pointer",
> which is why the error string is "Bad address". It makes absolutely NO
> SENSE here. Perhaps EEXIST or EBUSY.
>

Right. In current scenario it should have been EEXIST :(.

debugfs_create_dir() currently returns NULL dentry on both
EEXIST, ENOMEM ... cases.

Could one solution be cascading actual error
that is lost in fs/debugfs/inode.c:__create_file(), so that we could
take correct action in case of failure of debugfs_create_dir()?

(ugly side is we increase total number of params for __create_file to
6). or I hope there could be some better solution.

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




== 2 of 2 ==
Date: Tues, Oct 29 2013 12:40 pm
From: Linus Torvalds


On Tue, Oct 29, 2013 at 12:27 PM, Raghavendra K T
<raghavendra.kt@linux.vnet.ibm.com> wrote:
>
> Could one solution be cascading actual error
> that is lost in fs/debugfs/inode.c:__create_file(), so that we could
> take correct action in case of failure of debugfs_create_dir()?
>
> (ugly side is we increase total number of params for __create_file to
> 6). or I hope there could be some better solution.

The solution to this would be to simply return an error-pointer. See
<linux/err.h>. That's what we do for most complex subsystems that
return a pointer to a struct: rather than returning "NULL" as an
error, return the actual error number encoded in the pointer itself.

But that would require every user of debugfs_create_dir() to be
updated to check errors using IS_ERR() instead of checking against
NULL, and there's quite a few of them.

So I think just making the error be EEXIST is a simpler solution right now.

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





==============================================================================
TOPIC: kernel: use lockless list for smp_call_function_single
http://groups.google.com/group/linux.kernel/t/6e0e06d759089a1f?hl=en
==============================================================================

== 1 of 2 ==
Date: Tues, Oct 29 2013 12:30 pm
From: Jan Kara


On Thu 24-10-13 08:19:27, Christoph Hellwig wrote:
> Make smp_call_function_single and friends more efficient by using
> a lockless list.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---
> include/linux/blkdev.h | 5 +----
> include/linux/smp.h | 6 +++++-
> kernel/smp.c | 51 ++++++++++++------------------------------------
> 3 files changed, 19 insertions(+), 43 deletions(-)
>
> diff --git a/include/linux/blkdev.h b/include/linux/blkdev.h
> index f26ec20f..287bf7c 100644
> --- a/include/linux/blkdev.h
> +++ b/include/linux/blkdev.h
> @@ -95,10 +95,7 @@ enum rq_cmd_type_bits {
> * as well!
> */
> struct request {
> - union {
> - struct list_head queuelist;
> - struct llist_node ll_list;
> - };
> + struct list_head queuelist;
> union {
> struct call_single_data csd;
> struct work_struct mq_flush_data;
> diff --git a/include/linux/smp.h b/include/linux/smp.h
> index 7885151..10755dd 100644
> --- a/include/linux/smp.h
> +++ b/include/linux/smp.h
> @@ -11,12 +11,16 @@
> #include <linux/list.h>
> #include <linux/cpumask.h>
> #include <linux/init.h>
> +#include <linux/llist.h>
>
> extern void cpu_idle(void);
>
> typedef void (*smp_call_func_t)(void *info);
> struct call_single_data {
> - struct list_head list;
> + union {
> + struct list_head list;
> + struct llist_node llist;
> + };
I'm wondering: Who's still using the normal list_head? I was grepping for
a while and I couldn't find any user. Otherwise the patch looks good to me.
You can add:
Reviewed-by: Jan Kara <jack@suse.cz>

Honza

> smp_call_func_t func;
> void *info;
> u16 flags;
> diff --git a/kernel/smp.c b/kernel/smp.c
> index 53644e6..a735c66 100644
> --- a/kernel/smp.c
> +++ b/kernel/smp.c
> @@ -28,12 +28,7 @@ struct call_function_data {
>
> static DEFINE_PER_CPU_SHARED_ALIGNED(struct call_function_data, cfd_data);
>
> -struct call_single_queue {
> - struct list_head list;
> - raw_spinlock_t lock;
> -};
> -
> -static DEFINE_PER_CPU_SHARED_ALIGNED(struct call_single_queue, call_single_queue);
> +static DEFINE_PER_CPU_SHARED_ALIGNED(struct llist_head, call_single_queue);
>
> static int
> hotplug_cfd(struct notifier_block *nfb, unsigned long action, void *hcpu)
> @@ -85,12 +80,8 @@ void __init call_function_init(void)
> void *cpu = (void *)(long)smp_processor_id();
> int i;
>
> - for_each_possible_cpu(i) {
> - struct call_single_queue *q = &per_cpu(call_single_queue, i);
> -
> - raw_spin_lock_init(&q->lock);
> - INIT_LIST_HEAD(&q->list);
> - }
> + for_each_possible_cpu(i)
> + init_llist_head(&per_cpu(call_single_queue, i));
>
> hotplug_cfd(&hotplug_cfd_notifier, CPU_UP_PREPARE, cpu);
> register_cpu_notifier(&hotplug_cfd_notifier);
> @@ -141,18 +132,9 @@ static void csd_unlock(struct call_single_data *csd)
> */
> static void generic_exec_single(int cpu, struct call_single_data *csd, int wait)
> {
> - struct call_single_queue *dst = &per_cpu(call_single_queue, cpu);
> - unsigned long flags;
> - int ipi;
> -
> if (wait)
> csd->flags |= CSD_FLAG_WAIT;
>
> - raw_spin_lock_irqsave(&dst->lock, flags);
> - ipi = list_empty(&dst->list);
> - list_add_tail(&csd->list, &dst->list);
> - raw_spin_unlock_irqrestore(&dst->lock, flags);
> -
> /*
> * The list addition should be visible before sending the IPI
> * handler locks the list to pull the entry off it because of
> @@ -164,7 +146,7 @@ static void generic_exec_single(int cpu, struct call_single_data *csd, int wait)
> * locking and barrier primitives. Generic code isn't really
> * equipped to do the right thing...
> */
> - if (ipi)
> + if (llist_add(&csd->llist, &per_cpu(call_single_queue, cpu)))
> arch_send_call_function_single_ipi(cpu);
>
> if (wait)
> @@ -177,27 +159,26 @@ static void generic_exec_single(int cpu, struct call_single_data *csd, int wait)
> */
> void generic_smp_call_function_single_interrupt(void)
> {
> - struct call_single_queue *q = &__get_cpu_var(call_single_queue);
> - LIST_HEAD(list);
> + struct llist_node *entry, *next;
>
> /*
> * Shouldn't receive this interrupt on a cpu that is not yet online.
> */
> WARN_ON_ONCE(!cpu_online(smp_processor_id()));
>
> - raw_spin_lock(&q->lock);
> - list_replace_init(&q->list, &list);
> - raw_spin_unlock(&q->lock);
> + entry = llist_del_all(&__get_cpu_var(call_single_queue));
> + entry = llist_reverse_order(entry);
>
> - while (!list_empty(&list)) {
> + while (entry) {
> struct call_single_data *csd;
>
> - csd = list_entry(list.next, struct call_single_data, list);
> - list_del(&csd->list);
> + next = entry->next;
>
> + csd = llist_entry(entry, struct call_single_data, llist);
> csd->func(csd->info);
> -
> csd_unlock(csd);
> +
> + entry = next;
> }
> }
>
> @@ -410,17 +391,11 @@ void smp_call_function_many(const struct cpumask *mask,
>
> for_each_cpu(cpu, cfd->cpumask) {
> struct call_single_data *csd = per_cpu_ptr(cfd->csd, cpu);
> - struct call_single_queue *dst =
> - &per_cpu(call_single_queue, cpu);
> - unsigned long flags;
>
> csd_lock(csd);
> csd->func = func;
> csd->info = info;
> -
> - raw_spin_lock_irqsave(&dst->lock, flags);
> - list_add_tail(&csd->list, &dst->list);
> - raw_spin_unlock_irqrestore(&dst->lock, flags);
> + llist_add(&csd->llist, &per_cpu(call_single_queue, cpu));
> }
>
> /* Send a message to all CPUs in the map */
> --
> 1.7.10.4
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
Jan Kara <jack@suse.cz>
SUSE Labs, CR
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/




== 2 of 2 ==
Date: Tues, Oct 29 2013 12:30 pm
From: Christoph Hellwig


On Tue, Oct 29, 2013 at 08:25:36PM +0100, Jan Kara wrote:
> I'm wondering: Who's still using the normal list_head? I was grepping for
> a while and I couldn't find any user. Otherwise the patch looks good to me.

The block/blk-softirq.c code is abusing it in a fairly ugly way.

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





==============================================================================
TOPIC: Subject: [v3.8][v3.11][Regression] [SCSI] sd: Update WRITE SAME
heuristics
http://groups.google.com/group/linux.kernel/t/5bf81d6615c1244f?hl=en
==============================================================================

== 1 of 4 ==
Date: Tues, Oct 29 2013 12:30 pm
From: Joseph Salisbury


Hi Martin,

A bug was opened against the Ubuntu kernel[0]. After a kernel bisect,
it was found that reverting the following commit resolved this bug:

commit 66c28f97120e8a621afd5aa7a31c4b85c547d33d
Author: Martin K. Petersen <martin.petersen@oracle.com>
Date: Thu Jun 6 22:15:55 2013 -0400

[SCSI] sd: Update WRITE SAME heuristics


The regression was introduced as of v3.11-rc1, but it also made it's way
into the stable trees.

I see that you are the author of this patch, so I wanted to run this by
you. I was thinking of requesting a revert for v3.12, but I wanted to
get your feedback first.


Thanks,

Joe

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




== 2 of 4 ==
Date: Tues, Oct 29 2013 12:50 pm
From: Douglas Gilbert


On 13-10-29 03:21 PM, Joseph Salisbury wrote:
> Hi Martin,
>
> A bug was opened against the Ubuntu kernel[0]. After a kernel bisect,
> it was found that reverting the following commit resolved this bug:
>
> commit 66c28f97120e8a621afd5aa7a31c4b85c547d33d
> Author: Martin K. Petersen <martin.petersen@oracle.com>
> Date: Thu Jun 6 22:15:55 2013 -0400
>
> [SCSI] sd: Update WRITE SAME heuristics
>
>
> The regression was introduced as of v3.11-rc1, but it also made it's way
> into the stable trees.
>
> I see that you are the author of this patch, so I wanted to run this by
> you. I was thinking of requesting a revert for v3.12, but I wanted to
> get your feedback first.
>
>
> Thanks,
>
> Joe
>
> [0] http://pad.lv/1237392

Tried the other approach?

From your bug report: "Areca Raid Controller2: F/W v1.46 ...(etc)..."

Then see:
http://www.areca.com.tw/support/main.htm

Doug Gilbert



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




== 3 of 4 ==
Date: Tues, Oct 29 2013 12:50 pm
From: Bernd Schubert


Hello Joseph,

On 10/29/2013 08:21 PM, Joseph Salisbury wrote:
> Hi Martin,
>
> A bug was opened against the Ubuntu kernel[0]. After a kernel bisect,
> it was found that reverting the following commit resolved this bug:
>
> commit 66c28f97120e8a621afd5aa7a31c4b85c547d33d
> Author: Martin K. Petersen <martin.petersen@oracle.com>
> Date: Thu Jun 6 22:15:55 2013 -0400
>
> [SCSI] sd: Update WRITE SAME heuristics
>
>
> The regression was introduced as of v3.11-rc1, but it also made it's way
> into the stable trees.
>
> I see that you are the author of this patch, so I wanted to run this by
> you. I was thinking of requesting a revert for v3.12, but I wanted to
> get your feedback first.
>

James queued this up for 3.13

> http://git.kernel.org/cgit/linux/kernel/git/jejb/scsi.git/commit/?id=735e39e680256a13e7be3492acfb4d9721287a42

Maybe we should try to convince James to take it into 3.12?


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




== 4 of 4 ==
Date: Tues, Oct 29 2013 1:00 pm
From: Joseph Salisbury


On 10/29/2013 03:41 PM, Douglas Gilbert wrote:
> On 13-10-29 03:21 PM, Joseph Salisbury wrote:
>> Hi Martin,
>>
>> A bug was opened against the Ubuntu kernel[0]. After a kernel bisect,
>> it was found that reverting the following commit resolved this bug:
>>
>> commit 66c28f97120e8a621afd5aa7a31c4b85c547d33d
>> Author: Martin K. Petersen <martin.petersen@oracle.com>
>> Date: Thu Jun 6 22:15:55 2013 -0400
>>
>> [SCSI] sd: Update WRITE SAME heuristics
>>
>>
>> The regression was introduced as of v3.11-rc1, but it also made it's way
>> into the stable trees.
>>
>> I see that you are the author of this patch, so I wanted to run this by
>> you. I was thinking of requesting a revert for v3.12, but I wanted to
>> get your feedback first.
>>
>>
>> Thanks,
>>
>> Joe
>>
>> [0] http://pad.lv/1237392
>
> Tried the other approach?
>
> From your bug report: "Areca Raid Controller2: F/W v1.46 ...(etc)..."
>
> Then see:
> http://www.areca.com.tw/support/main.htm
>
> Doug Gilbert
>
>
>
Thanks, Doug. I'm going to give the patch[0] written by Bernd Schubert
a try first. If the issue still persists, I'll ask the bug reporter to
upgrade the firmware.

[0]
http://git.kernel.org/cgit/linux/kernel/git/jejb/scsi.git/commit/?id=735e39e680256a13e7be3492acfb4d9721287a42

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





==============================================================================
TOPIC: perf events ring buffer memory barrier on powerpc
http://groups.google.com/group/linux.kernel/t/d7e2f84d9477fb85?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Oct 29 2013 12:30 pm
From: Vince Weaver


On Tue, 29 Oct 2013, Peter Zijlstra wrote:

> On Tue, Oct 29, 2013 at 11:21:31AM +0100, Peter Zijlstra wrote:
> --- linux-2.6.orig/include/uapi/linux/perf_event.h
> +++ linux-2.6/include/uapi/linux/perf_event.h
> @@ -479,13 +479,15 @@ struct perf_event_mmap_page {
> /*
> * Control data for the mmap() data buffer.
> *
> - * User-space reading the @data_head value should issue an rmb(), on
> - * SMP capable platforms, after reading this value -- see
> - * perf_event_wakeup().
> + * User-space reading the @data_head value should issue an smp_rmb(),
> + * after reading this value.

so where's the patch fixing perf to use the new recommendations?

Is this purely a performance thing or a correctness change?

A change like this a bit of a pain, especially as userspace doesn't really
have nice access to smb_mb() defines so a lot of cut-and-pasting will
ensue for everyone who's trying to parse the mmap buffer.

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





==============================================================================
TOPIC: ARM seccomp filters and EABI/OABI
http://groups.google.com/group/linux.kernel/t/53f42e90df679dd4?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Oct 29 2013 12:40 pm
From: Paul Moore


On Monday, October 28, 2013 11:16:20 PM Richard Weinberger wrote:
> Am 28.10.2013 22:53, schrieb Paul Moore:
> > On Thursday, October 24, 2013 09:55:57 PM Richard Weinberger wrote:
> >> On Wed, Oct 23, 2013 at 11:02 PM, Andy Lutomirski <luto@amacapital.net>
> >
> > wrote:
> >>> I'm looking at the seccomp code, the ARM entry code, and the
> >>> syscall(2) manpage, and I'm a bit lost. (The fact that I don't really
> >>> speak ARM assembly doesn't help.) My basic question is: what happens
> >>> if an OABI syscall happens?
> >>>
> >>> AFAICS, the syscall arguments for EABI are r0..r5, although their
> >>> ordering is a bit odd*. For OABI, r6 seems to play some role, but I'm
> >>> lost as to what it is. The seccomp_bpf_load function won't load r6,
> >>> so there had better not be anything useful in there... (Also, struct
> >>> seccomp_data will have issues with a seventh "argument".)
> >>>
> >>> But what happens to the syscall number? For an EABI syscall, it's in
> >>> r7. For an OABI syscall, it's in the swi instruction and gets copied
> >>> to r7 on entry. If a debugger changes r7, presumably the syscall
> >>> number changes.
> >>>
> >>> Oddly, there are two different syscall tables. The major differences
> >>> seem to be that some of the OABI entries have their argument order
> >>> changed. But there's also a magic constant 0x900000 added to the
> >>> syscall number somewhere -- is it reflected in _sigsys._syscall? Is
> >>> it reflected in ucontext's r7?
> >>>
> >>> I'm a bit surprised to see that both the EABI and OABI ABIs show up as
> >>> AUDIT_ARCH_ARM.
> >>>
> >>> Can any of you shed some light on this? I don't have an ARM system I
> >>> can test on, but if one of you can point me at a decent QEMU image, I
> >>> can play around.
> >>
> >> Maybe this helps:
> >> http://people.debian.org/~aurel32/qemu/armel/
> >
> > Thanks for the pointer, although those images look quite old, has anyone
> > done a refresh?
>
> You are free to run "apt-get upgrade" within the said images. :-)

Okay, true ;)

--
paul moore
www.paul-moore.com

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





==============================================================================
TOPIC: Move drivers/acpi/apei/cper.c to drivers/firmware/efi/
http://groups.google.com/group/linux.kernel/t/fed644237d7ddfa7?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Oct 29 2013 12:40 pm
From: "Luck, Tony"


The following changes since commit 56507694de3453076d73e0e9813349586ee67e59:

EDAC, GHES: Update ghes error record info (2013-10-23 10:11:00 -0700)

are available in the git repository at:

git://git.kernel.org/pub/scm/linux/kernel/git/ras/ras.git tags/please-pull-move-cper

for you to fetch changes up to c57a801195153e111bcd712680a718cf101b6d1f:

Move cper.c from drivers/acpi/apei to drivers/firmware/efi (2013-10-29 09:23:38 -0700)

----------------------------------------------------------------
cper.c implements UEFI Appendix N "Common Platform Error Record"
handling. Move it to drivers/firmware/efi/cper.c to reflect this
heritage.

----------------------------------------------------------------
Tony Luck (1):
Move cper.c from drivers/acpi/apei to drivers/firmware/efi

drivers/acpi/Kconfig | 4 +++-
drivers/acpi/apei/Kconfig | 2 ++
drivers/acpi/apei/Makefile | 2 +-
drivers/firmware/efi/Kconfig | 3 +++
drivers/firmware/efi/Makefile | 1 +
drivers/{acpi/apei => firmware/efi}/cper.c | 0
6 files changed, 10 insertions(+), 2 deletions(-)
rename drivers/{acpi/apei => firmware/efi}/cper.c (100%)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/





==============================================================================
TOPIC: Revert 9745cdb36da83aeec198650b410ca06304cf792 ("select: use freezable
blocking call")?
http://groups.google.com/group/linux.kernel/t/d5781c359b092c6c?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Oct 29 2013 12:50 pm
From: Paul Bolle


0) Summary: ever since I tried running (release candidates of) v3.11 on
the two working i686s I still have lying around I ran into issues on
resuming from suspend. Reverting 9745cdb36da83aeec198650b410ca06304cf792
("select: use freezable blocking call") resolves those issues.

1) Resuming from suspend on i686 on (release candidates of) v3.11 and
later triggers issues like:
traps: systemd[1] general protection ip:b738e490 sp:bf882fc0 error:0 in libc-2.16.so[b731c000+1b0000]

and
traps: rtkit-daemon[552] general protection ip:804d6e5 sp:b6cb32f0 error:0 in rtkit-daemon[8048000+d000]

Once I hit the systemd error I can only get out of the mess that the
system is at that point by power cycling it.

2) I bisected that issue to commit
9745cdb36da83aeec198650b410ca06304cf792 ("select: use freezable blocking
call"). The, rather impressive, bisect log is pasted at the end of this
message. It took 23 builds to pinpoint this issue in the v3.10..v3.11
range! Sadly, I have no clue why that commit triggers this issue.

3) Reverting that commit on top of v3.12-rc7 gets me a system that
resumes without issues. (That revert needed one trivial context change.
Note that I haven't actually tried v3.12-rc7 plain. But v3.12-rc6 and
earlier also had this issue, so I'm sure the revert did the trick for
v3.12-rc7.)

4) Should this commit be reverted? Or is there a better fix?


Paul Bolle

# bad: [6e4664525b1db28f8c4e1130957f70a94c19213e] Linux 3.11
# good: [8bb495e3f02401ee6f76d1b1d77f3ac9f079e376] Linux 3.10
git bisect start 'v3.11' 'v3.10'
# bad: [8b70a90cabafb6a6e1a0d3f838b38355fe48337e] Merge branch 'for-v3.11' of git://git.linaro.org/people/mszyprowski/linux-dma-mapping
git bisect bad 8b70a90cabafb6a6e1a0d3f838b38355fe48337e
# good: [ab3d681e9d41816f90836ea8fe235168d973207f] Merge branch 'core-rcu-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
git bisect good ab3d681e9d41816f90836ea8fe235168d973207f
# bad: [862f0012549110d6f2586bf54b52ed4540cbff3a] Merge tag 'pci-v3.11-changes' of git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci
git bisect bad 862f0012549110d6f2586bf54b52ed4540cbff3a
# good: [60b5adffb4f3e4b4c1978959f24e8e531b2ef3cb] Merge tag 'gpio-for-v3.11-1' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio
git bisect good 60b5adffb4f3e4b4c1978959f24e8e531b2ef3cb
# good: [fe489bf4505ae26d3c6d6a1f1d3064c2a9c5cd85] Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm
git bisect good fe489bf4505ae26d3c6d6a1f1d3064c2a9c5cd85
# skip: [405a1086bdd091d2d55db0ac905cd6332b35cec1] Merge branch 'pm-cpufreq'
git bisect skip 405a1086bdd091d2d55db0ac905cd6332b35cec1
# good: [f4fd3797848aa04e72e942c855fd279840a47fe4] acpi-cpufreq: Add new sysfs attribute freqdomain_cpus
git bisect good f4fd3797848aa04e72e942c855fd279840a47fe4
# bad: [2c843bd92ec276ecb68504b3b5ffa7066183f032] Merge branch 'pm-cpufreq'
git bisect bad 2c843bd92ec276ecb68504b3b5ffa7066183f032
# skip: [e8b6cb3947430d62538d88f615c007a51aeb23fe] Merge branch 'acpi-doc'
git bisect skip e8b6cb3947430d62538d88f615c007a51aeb23fe
# good: [1d1ea1b723d9f239f736b8cf284327cbbf9d15d1] ACPICA: Standardize all switch() blocks
git bisect good 1d1ea1b723d9f239f736b8cf284327cbbf9d15d1
# skip: [e52cff8bdd4a30c40a7f65c7ea8f1f425f8a15eb] Merge branch 'pm-assorted'
git bisect skip e52cff8bdd4a30c40a7f65c7ea8f1f425f8a15eb
# good: [39688ce6facd63de796def41a0b9012882b5cc14] PM / devfreq: account suspend/resume for stats
git bisect good 39688ce6facd63de796def41a0b9012882b5cc14
# good: [173a5a4c909789fcd57d00355d2237618a3824a4] ACPI / processor: Fix potential NULL pointer dereference in acpi_processor_add()
git bisect good 173a5a4c909789fcd57d00355d2237618a3824a4
# skip: [207bc1181b1c03ab6ecb55bca5b307606dd1d6bc] Merge branch 'freezer'
git bisect skip 207bc1181b1c03ab6ecb55bca5b307606dd1d6bc
# good: [613f5d13b569859171f0896fbc73ee0bfa811fda] freezer: skip waking up tasks with PF_FREEZER_SKIP set
git bisect good 613f5d13b569859171f0896fbc73ee0bfa811fda
# good: [9b5c7a5a977a330ffaf83c4d383ba247c74c800f] ACPI / PM: Fix possible NULL pointer deref in acpi_pm_device_sleep_state()
git bisect good 9b5c7a5a977a330ffaf83c4d383ba247c74c800f
# good: [45f0a85c8258741d11bda25c0a5669c06267204a] PM / Runtime: Rework the "runtime idle" helper routine
git bisect good 45f0a85c8258741d11bda25c0a5669c06267204a
# bad: [2cc6ced132f472b2bdb619960a650b9a85cdd34f] Merge branch 'pm-cpufreq'
git bisect bad 2cc6ced132f472b2bdb619960a650b9a85cdd34f
# good: [d24c2a4f919d17bd1ae4f4010a38ab07ece99cf7] PM / QoS: correct the valid range of pm_qos_class
git bisect good d24c2a4f919d17bd1ae4f4010a38ab07ece99cf7
# bad: [2b15af6f953012aac49984ead3f8ec744d941540] af_unix: use freezable blocking calls in read
git bisect bad 2b15af6f953012aac49984ead3f8ec744d941540
# good: [1c441e921201d523b5a6036aea22b0b426bf1af2] epoll: use freezable blocking call
git bisect good 1c441e921201d523b5a6036aea22b0b426bf1af2
# bad: [56467c7697f5aef6974501fbe2c3e63674583549] futex: use freezable blocking call
git bisect bad 56467c7697f5aef6974501fbe2c3e63674583549
# bad: [9745cdb36da83aeec198650b410ca06304cf7928] select: use freezable blocking call
git bisect bad 9745cdb36da83aeec198650b410ca06304cf7928

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





==============================================================================
TOPIC: Support for perf to probe into SDT markers:
http://groups.google.com/group/linux.kernel/t/03ad07929773e148?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Oct 29 2013 12:50 pm
From: Hemant Kumar


On 10/29/2013 07:35 PM, Pekka Enberg wrote:
> On 10/29/2013 11:55 AM, Hemant Kumar wrote:
>> 1. Where this cache should be? Keeping it in tracing directory inside
>> the debugfs
>> directory should seem more feasible. And, shall this cache be shareable?
>
> You can't share all of the cache because otherwise you'll expose
> details on binaries that not everyone has access to.

Correct, that was one of the reason to be worried. And since, to a
normal user debugfs is not allowed to be entered, then we can keep that
inside debugfs/tracing subdirectory.

>
> It might make sense to split the cache into two parts: system markers
> and user markers and share the former.
>

Ok...

>> 2. perf record is a performance intensive process, can we allow the
>> delay due to
>> this searching process here?
>
> I think scanning is OK if the user specified a SDT markers but not
> otherwise.
>
> Perhaps you can use a bloom filter to quickly check if the user passed
> a SDT marker or not.
>

True, bloom filters may help in this case with a quick check.

--
Thanks
Hemant Kumar

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





==============================================================================
TOPIC: clk: Implement clk_unregister()
http://groups.google.com/group/linux.kernel/t/8b342eba360d1672?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Oct 29 2013 1:00 pm
From: Sylwester Nawrocki


clk_unregister() is currently not implemented and it is required when
a clock provider module needs to be unloaded.

Normally the clock supplier module is prevented to be unloaded by
taking reference on the module in clk_get().

For cases when the clock supplier module deinitializes despite the
consumers of its clocks holding a reference on the module, e.g. when
the driver is unbound through "unbind" sysfs attribute, there are
empty clock ops added. These ops are assigned temporarily to struct
clk and used until all consumers release the clock, to avoid invoking
callbacks from the module which just got removed.

Signed-off-by: Jiada Wang <jiada_wang@mentor.com>
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
---
Changes since v6:
- fixed NULL clk handling and replaced pr_err() with WARN_ON_ONCE().

Changes since v4:
- none.

Changes since v3:
- Use WARN_ON_ONCE() rather than WARN_ON() in clk_nodrv_disable_unprepare()
callback.

Changes since v2:
- none.

Changes since RFC v1:
- renamed clk_dummy_* to clk_nodrv_*.
---
drivers/clk/clk.c | 121 +++++++++++++++++++++++++++++++++++++++++--
include/linux/clk-private.h | 2 +
2 files changed, 120 insertions(+), 3 deletions(-)

diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index 25b249c..7a33961 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -344,6 +344,21 @@ out:
return ret;
}

+ /**
+ * clk_debug_unregister - remove a clk node from the debugfs clk tree
+ * @clk: the clk being removed from the debugfs clk tree
+ *
+ * Dynamically removes a clk and all it's children clk nodes from the
+ * debugfs clk tree if clk->dentry points to debugfs created by
+ * clk_debug_register in __clk_init.
+ *
+ * Caller must hold prepare_lock.
+ */
+static void clk_debug_unregister(struct clk *clk)
+{
+ debugfs_remove_recursive(clk->dentry);
+}
+
/**
* clk_debug_reparent - reparent clk node in the debugfs clk tree
* @clk: the clk being reparented
@@ -434,6 +449,9 @@ static inline int clk_debug_register(struct clk *clk) { return 0; }
static inline void clk_debug_reparent(struct clk *clk, struct clk *new_parent)
{
}
+static inline void clk_debug_unregister(struct clk *clk)
+{
+}