Re: [PATCH net] ipv6: Prevent ipv6_find_hdr() from returning ENOENT for valid non-first fragments

[Rahul Sharma]

Hi Pablo,

On Fri, Jan 9, 2015 at 5:35 AM, Pablo Neira Ayuso  wrote:
> On Thu, Jan 08, 2015 at 11:39:16PM +0100, Hannes Frederic Sowa wrote:
>> Hi Pablo,
>>
>> On Thu, Jan 8, 2015, at 21:53, Pablo Neira Ayuso wrote:
>> > I'm afraid we cannot just get rid of that !ipv6_ext_hdr() check. The
>> > ipv6_find_hdr() function is designed to return the transport protocol.
>> > After the proposed change, it will return extension header numbers.
>> > This will break existing ip6tables rulesets since the `-p' option
>> > relies on this function to match the transport protocol.
>> >
>> > Note that the AH header is skipped (see code a bit below this
>> > problematic fragmentation handling) so the follow up header after the
>> > AH header is returned as the transport header.
>> >
>> > We can probably return the AH protocol number for non-1st fragments.
>> > However, that would be something new to ip6tables since nobody has
>> > ever seen packet matching `-p ah' rules. Thus, we restore control to
>> > the user to allow this, but we would accept all kind of fragmented AH
>> > traffic through the firewall since we cannot know what transport
>> > protocol contains from non-1st fragments (unless I'm missing anything,
>> > I need to have a closer look at this again tomorrow with fresher
>> > mind).
>>
>> The code in question is guarded by (_frag_off != 0), so we are
>> definitely processing a non-1st fragment currently. The -p match would
>> happen at the time when the packet is reassembled and thus ipv6_find_hdr
>> will find the real transport (final) header at this point (I hope I
>> followed the code correctly here).
>
> Then, Rahul should get things working by modprobing nf_defrag_ipv6.

I already had nf_defrag_ipv6 installed when the issue occured. But I
see ip6table_raw_hook returning NF_DROP for the second fragment.

Thanks,
Rahul
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/6] btwilink: add minimal device tree support

[Marcel Holtmann]

Hi Gigi,

> Add minimal device tree support to the btwilink driver that is used
> for binding bluetooth with the ti-st shared transport driver.
> 
> Signed-off-by: Eyal Reizer 
> Signed-off-by: bvijay 
> Signed-off-by: Gigi Joseph 
> ---
> drivers/bluetooth/btwilink.c | 11 +++
> 1 file changed, 11 insertions(+)
> 
> diff --git a/drivers/bluetooth/btwilink.c b/drivers/bluetooth/btwilink.c
> index 55c135b..95adec3 100644
> --- a/drivers/bluetooth/btwilink.c
> +++ b/drivers/bluetooth/btwilink.c
> @@ -30,6 +30,7 @@
> 
> #include 
> #include 
> +#include 
> 
> /* Bluetooth Driver Version */
> #define VERSION   "1.0"
> @@ -286,6 +287,14 @@ static int ti_st_send_frame(struct hci_dev *hdev, struct 
> sk_buff *skb)
>   return 0;
> }
> 
> +static const struct of_device_id btwilink_of_match[] = {
> +{
> + .compatible = "btwilink",
> + },
> + {}
> +};

this formatting is bogus. Please construct it similar to what other drivers are 
doing.

static const struct .. = {
{ .compatible = ".." },

{ } /* Terminating entry */
};

And add an extra empty line before MODULE_DEVICE_TABLE.

> +MODULE_DEVICE_TABLE(of, btwilink_of_match);
> +
> static int bt_ti_probe(struct platform_device *pdev)
> {
>   static struct ti_st *hst;
> @@ -349,6 +358,8 @@ static struct platform_driver btwilink_driver = {
>   .remove = bt_ti_remove,
>   .driver = {
>   .name = "btwilink",
> + .owner = THIS_MODULE,
> + .of_match_table = of_match_ptr(btwilink_of_match),
>   },
> };

Regards

Marcel

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] Add TI CDCE925 I2C controlled clock synthesizer driver

[Mike Looijmans]

Just a ping to inform if you've had had time to look at this?

Mike.

On 12/04/2014 08:26 AM, Mike Looijmans wrote:

This driver supports the TI CDCE925 programmable clock synthesizer.
The chip contains two PLLs with spread-spectrum clocking support and
five output dividers. The driver only supports the following setup,
and uses a fixed setting for the output muxes:
   Y1 is derived from the input clock
   Y2 and Y3 derive from PLL1
   Y4 and Y5 derive from PLL2
Given a target output frequency, the driver will set the PLL and
divider to best approximate the desired output.

Signed-off-by: Mike Looijmans 
---

v2: Coding style check
 Add devicetree binding documentation

  .../devicetree/bindings/clock/cdce925.txt  |   61 ++
  drivers/clk/Kconfig|   17 +
  drivers/clk/Makefile   |1 +
  drivers/clk/clk-cdce925.c  |  792 
  4 files changed, 871 insertions(+)
  create mode 100644 Documentation/devicetree/bindings/clock/cdce925.txt
  create mode 100644 drivers/clk/clk-cdce925.c

diff --git a/Documentation/devicetree/bindings/clock/cdce925.txt 
b/Documentation/devicetree/bindings/clock/cdce925.txt
new file mode 100644
index 000..0eac770
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/cdce925.txt
@@ -0,0 +1,61 @@
+Binding for TO CDCE925 programmable I2C clock synthesizers.
+
+Reference
+This binding uses the common clock binding[1].
+
+[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
+[2] http://www.ti.com/product/cdce925
+
+Required properties:
+ - compatible: Shall be one of "cdce925", "cdce925pw",
+ - reg: I2C device address.
+ - clocks: Points to a fixed parent clock that provides the input frequency.
+ - #clock-cells: From common clock bindings: Shall be 1.
+
+Optional properties:
+ - xtal-load-pf: Crystal load-capacitor value to fine-tune performance on a
+ board, or to compensate for external influences.
+
+
+For each connected output Y1 through Y5, a child node should be provided. Each
+child node must have the following properties:
+ - #clock-cells: From common clock bindings: Shall be 0.
+Optional properties for the output nodes:
+ - clock-frequency: Output frequency to generate. This defines the output
+   frequency set during boot. It can be reprogrammed during
+   runtime through the common clock framework.
+
+For both PLL1 and PLL2 an optional child node can be used to specify spread
+spectrum clocking parameters.
+  - spread-spectrum: SSC mode as defined in the data sheet.
+  - spread-spectrum-center: Use "centered" mode instead of "max" mode. When 
this
+is present, the clock runs at the requested frequency on average.
+
+
+Example:
+
+   clockgen: cdce925pw@64 {
+   compatible = "cdce925";
+   reg = <0x64>;
+   clocks = <_27Mhz>;
+   xtal-load-pf = <5>;
+   #clock-cells = <1>;
+   /* PLL options to get SSC 1% centered */
+   PLL2 {
+   spread-spectrum = <4>;
+   spread-spectrum-center;
+   };
+   /* Outputs calculate mux and divider settings */
+   Y1 {
+   #clock-cells = <0>;
+   clock-frequency = <27000>;
+   };
+   audio_clock: Y2 {
+   #clock-cells = <0>;
+   clock-frequency = <12288000>; /* SPDIF audio */
+   };
+   hdmi_pixel_clock: Y4 {
+   #clock-cells = <0>;
+   clock-frequency = <14850>; /* HD-video */
+   };
+   };
diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
index 455fd17..4e474b3 100644
--- a/drivers/clk/Kconfig
+++ b/drivers/clk/Kconfig
@@ -77,6 +77,23 @@ config COMMON_CLK_SI570
  This driver supports Silicon Labs 570/571/598/599 programmable
  clock generators.

+config COMMON_CLK_CDCE925
+   tristate "Clock driver for TI CDCE925 devices"
+   depends on I2C
+   depends on OF
+   select REGMAP_I2C
+   help
+   ---help---
+ This driver supports the TI CDCE925 programmable clock synthesizer.
+ The chip contains two PLLs with spread-spectrum clocking support and
+ five output dividers. The driver only supports the following setup,
+ and uses a fixed setting for the output muxes.
+ Y1 is derived from the input clock
+ Y2 and Y3 derive from PLL1
+ Y4 and Y5 derive from PLL2
+ Given a target output frequency, the driver will set the PLL and
+ divider to best approximate the desired output.
+
  config COMMON_CLK_S2MPS11
tristate "Clock driver for S2MPS1X/S5M8767 MFD"
depends on MFD_SEC_CORE
diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index d5fba5b..c476066 100644
--- a/drivers/clk/Makefile
+++ 

Re: [PATCH 2/3] gpio: dln2: use bus_sync_unlock instead of scheduling work

[Linus Walleij]

On Fri, Jan 9, 2015 at 12:40 AM, Octavian Purdila
 wrote:
> On Thu, Jan 1, 2015 at 9:56 AM, Linus Walleij  
> wrote:
>> On Thu, Dec 11, 2014 at 2:02 PM, Octavian Purdila
>>  wrote:
>>
>>> Use the irq_chip bus_sync_unlock method to update hardware registers
>>> instead of scheduling work from the mask/unmask methods. This simplifies
>>> a bit the driver and make it more uniform with the other GPIO IRQ
>>> drivers.
>>>
>>> Signed-off-by: Octavian Purdila 
>>
>> Patch applied for fixes.
>>
>
> Hi Linus,
>
> I don't see the patch applied, could you please consider it for the
> -for-next branch?

Ah sorry I thought only the first patch was a critical fix.
Applied this to fixes too now. Working on queueing the
GPIO fixes.

Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v19 08/11] ARM: kprobes: enable OPTPROBES for ARM 32

[Wang Nan]

Hi Tixy and other,

Similar to patch 01/11, build robot found a building error in this patch when 
ARM version
is lower than 4. In such processors 'blx' instruction is unusable.

I have posted a new version of this patch, which has following code change:

diff --git a/arch/arm/probes/kprobes/opt-arm.c 
b/arch/arm/probes/kprobes/opt-arm.c
index 6a60df3..cb47eff 100644
--- a/arch/arm/probes/kprobes/opt-arm.c
+++ b/arch/arm/probes/kprobes/opt-arm.c
@@ -58,7 +58,12 @@ asm (
 */
"   and r4, sp, #4\n"
"   sub sp, sp, r4\n"
+#if __LINUX_ARM_ARCH__ >= 5
"   blx r2\n"
+#else
+   "   mov lr, pc\n"
+   "   bx  r2\n"
+#endif
"   add sp, sp, r4\n"
"   ldr r1, [sp, #64]\n"
"   tst r1, #"__stringify(PSR_T_BIT)"\n"

http://lists.infradead.org/pipermail/linux-arm-kernel/2015-January/314542.html

Tixy, could you please collect it into your repository and test again?

Thank you!

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v20 08/11] ARM: kprobes: enable OPTPROBES for ARM 32

[Wang Nan]

This patch introduce kprobeopt for ARM 32.

Limitations:
 - Currently only kernel compiled with ARM ISA is supported.

 - Offset between probe point and optinsn slot must not larger than
   32MiB. Masami Hiramatsu suggests replacing 2 words, it will make
   things complex. Futher patch can make such optimization.

Kprobe opt on ARM is relatively simpler than kprobe opt on x86 because
ARM instruction is always 4 bytes aligned and 4 bytes long. This patch
replace probed instruction by a 'b', branch to trampoline code and then
calls optimized_callback(). optimized_callback() calls opt_pre_handler()
to execute kprobe handler. It also emulate/simulate replaced instruction.

When unregistering kprobe, the deferred manner of unoptimizer may leave
branch instruction before optimizer is called. Different from x86_64,
which only copy the probed insn after optprobe_template_end and
reexecute them, this patch call singlestep to emulate/simulate the insn
directly. Futher patch can optimize this behavior.

Signed-off-by: Wang Nan 
Acked-by: Masami Hiramatsu 
Cc: Jon Medhurst (Tixy) 
Reviewed-by: Jon Medhurst (Tixy) 
Cc: Russell King - ARM Linux 
Cc: Will Deacon 
---
 arch/arm/Kconfig|   1 +
 arch/arm/{kernel => include/asm}/insn.h |   0
 arch/arm/include/asm/kprobes.h  |  29 +++
 arch/arm/kernel/Makefile|   2 +-
 arch/arm/kernel/ftrace.c|   3 +-
 arch/arm/kernel/jump_label.c|   3 +-
 arch/arm/probes/kprobes/Makefile|   1 +
 arch/arm/probes/kprobes/core.c  |  26 ++-
 arch/arm/probes/kprobes/core.h  |   2 +
 arch/arm/probes/kprobes/opt-arm.c   | 322 
 10 files changed, 377 insertions(+), 12 deletions(-)
 rename arch/arm/{kernel => include/asm}/insn.h (100%)
 create mode 100644 arch/arm/probes/kprobes/opt-arm.c

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 97d07ed..3d5dc2d 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -60,6 +60,7 @@ config ARM
select HAVE_MEMBLOCK
select HAVE_MOD_ARCH_SPECIFIC if ARM_UNWIND
select HAVE_OPROFILE if (HAVE_PERF_EVENTS)
+   select HAVE_OPTPROBES if !THUMB2_KERNEL
select HAVE_PERF_EVENTS
select HAVE_PERF_REGS
select HAVE_PERF_USER_STACK_DUMP
diff --git a/arch/arm/kernel/insn.h b/arch/arm/include/asm/insn.h
similarity index 100%
rename from arch/arm/kernel/insn.h
rename to arch/arm/include/asm/insn.h
diff --git a/arch/arm/include/asm/kprobes.h b/arch/arm/include/asm/kprobes.h
index 56f9ac6..50ff3bc 100644
--- a/arch/arm/include/asm/kprobes.h
+++ b/arch/arm/include/asm/kprobes.h
@@ -50,5 +50,34 @@ int kprobe_fault_handler(struct pt_regs *regs, unsigned int 
fsr);
 int kprobe_exceptions_notify(struct notifier_block *self,
 unsigned long val, void *data);
 
+/* optinsn template addresses */
+extern __visible kprobe_opcode_t optprobe_template_entry;
+extern __visible kprobe_opcode_t optprobe_template_val;
+extern __visible kprobe_opcode_t optprobe_template_call;
+extern __visible kprobe_opcode_t optprobe_template_end;
+extern __visible kprobe_opcode_t optprobe_template_sub_sp;
+extern __visible kprobe_opcode_t optprobe_template_add_sp;
+
+#define MAX_OPTIMIZED_LENGTH   4
+#define MAX_OPTINSN_SIZE   \
+   ((unsigned long)_template_end -\
+(unsigned long)_template_entry)
+#define RELATIVEJUMP_SIZE  4
+
+struct arch_optimized_insn {
+   /*
+* copy of the original instructions.
+* Different from x86, ARM kprobe_opcode_t is u32.
+*/
+#define MAX_COPIED_INSNDIV_ROUND_UP(RELATIVEJUMP_SIZE, 
sizeof(kprobe_opcode_t))
+   kprobe_opcode_t copied_insn[MAX_COPIED_INSN];
+   /* detour code buffer */
+   kprobe_opcode_t *insn;
+   /*
+* We always copy one instruction on ARM,
+* so size will always be 4, and unlike x86, there is no
+* need for a size field.
+*/
+};
 
 #endif /* _ARM_KPROBES_H */
diff --git a/arch/arm/kernel/Makefile b/arch/arm/kernel/Makefile
index 9c51a43..902397d 100644
--- a/arch/arm/kernel/Makefile
+++ b/arch/arm/kernel/Makefile
@@ -52,7 +52,7 @@ obj-$(CONFIG_FUNCTION_GRAPH_TRACER)   += ftrace.o insn.o
 obj-$(CONFIG_JUMP_LABEL)   += jump_label.o insn.o patch.o
 obj-$(CONFIG_KEXEC)+= machine_kexec.o relocate_kernel.o
 # Main staffs in KPROBES are in arch/arm/probes/ .
-obj-$(CONFIG_KPROBES)  += patch.o
+obj-$(CONFIG_KPROBES)  += patch.o insn.o
 obj-$(CONFIG_OABI_COMPAT)  += sys_oabi-compat.o
 obj-$(CONFIG_ARM_THUMBEE)  += thumbee.o
 obj-$(CONFIG_KGDB) += kgdb.o patch.o
diff --git a/arch/arm/kernel/ftrace.c b/arch/arm/kernel/ftrace.c
index b8c75e4..709ee1d 100644
--- a/arch/arm/kernel/ftrace.c
+++ b/arch/arm/kernel/ftrace.c
@@ -20,8 +20,7 @@
 #include 
 #include 
 #include 
-
-#include "insn.h"
+#include 
 
 #ifdef CONFIG_THUMB2_KERNEL
 #defineNOP 0xf85deb04   

Re: [PATCH tip/core/rcu 01/14] rcu: Protect rcu_boost() lockless accesses with ACCESS_ONCE()

[Davidlohr Bueso]

On Thu, 2015-01-08 at 07:22 -0800, Paul E. McKenney wrote:
> > Didn't we just obsolete ACCESS_ONCE with that {READ,WRITE}_ONCE stuff?
> 
> Indeed we did!  But that was after I did this commit back on October 29th.
> 
> I am planning a bulk change to READ_ONCE() and ASSIGN_ONCE() either as
> the last patch for 3.20 or as the first one for 3.21.  Probably as the
> first for 3.21 to minimize rebasing hassles with any needed 3.20 fixes.

That reminds me, I think the new conversion for stores will most likely
introduce silly arg bugs:

-   ACCESS_ONCE(a) = b;
+   ASSIGN_ONCE(b, a);

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 -mm v3 3/9] vmscan: per memory cgroup slab shrinkers

[Hillf Danton]

>  static bool shrink_zone(struct zone *zone, struct scan_control *sc,
>   bool is_classzone)
>  {
> + struct reclaim_state *reclaim_state = current->reclaim_state;
>   unsigned long nr_reclaimed, nr_scanned;
>   bool reclaimable = false;
> 
> @@ -2318,16 +2357,22 @@ static bool shrink_zone(struct zone *zone, struct 
> scan_control *sc,
> 
>   memcg = mem_cgroup_iter(root, NULL, );
>   do {
> - unsigned long lru_pages;
> + unsigned long lru_pages, scanned;
>   struct lruvec *lruvec;
>   int swappiness;
> 
>   lruvec = mem_cgroup_zone_lruvec(zone, memcg);
>   swappiness = mem_cgroup_swappiness(memcg);
> + scanned = sc->nr_scanned;
> 
>   shrink_lruvec(lruvec, swappiness, sc, _pages);
>   zone_lru_pages += lru_pages;
> 
> + if (memcg && is_classzone)
> + shrink_slab(sc->gfp_mask, zone_to_nid(zone),
> + memcg, sc->nr_scanned - scanned,
> + lru_pages);
> +
Looks sc->nr_reclaimed has to be updated for "limit reclaim".

Hillf
>   /*
>* Direct reclaim and kswapd have to scan all memory
>* cgroups to fulfill the overall scan target for the
> @@ -2350,19 +2395,14 @@ static bool shrink_zone(struct zone *zone, struct 
> scan_control *sc,
>* Shrink the slab caches in the same proportion that
>* the eligible LRU pages were scanned.
>*/
> - if (global_reclaim(sc) && is_classzone) {
> - struct reclaim_state *reclaim_state;
> -
> - shrink_node_slabs(sc->gfp_mask, zone_to_nid(zone),
> -   sc->nr_scanned - nr_scanned,
> -   zone_lru_pages);
> -
> - reclaim_state = current->reclaim_state;
> - if (reclaim_state) {
> - sc->nr_reclaimed +=
> - reclaim_state->reclaimed_slab;
> - reclaim_state->reclaimed_slab = 0;
> - }
> + if (global_reclaim(sc) && is_classzone)
> + shrink_slab(sc->gfp_mask, zone_to_nid(zone), NULL,
> + sc->nr_scanned - nr_scanned,
> + zone_lru_pages);
> +
> + if (reclaim_state) {
> + sc->nr_reclaimed += reclaim_state->reclaimed_slab;
> + reclaim_state->reclaimed_slab = 0;
>   }
> 
>   vmpressure(sc->gfp_mask, sc->target_mem_cgroup,
> --
> 1.7.10.4

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

Re: [RFC] usb: dwc3: add DWC3_SKIP_USB3PHY and DWC3_SKIP_USB2_PHY quirks

[Jisheng Zhang]

Hi Felipe,

On Thu, 8 Jan 2015 09:08:15 -0800
Felipe Balbi  wrote:

> Hi,
> 
> On Mon, Dec 08, 2014 at 09:35:51PM +0800, Jisheng Zhang wrote:
> > On platforms which has native usb hosts/phys and pci-dwc3 controller,
> > the dwc3 core may get the wrong usb2_phy and usb3_phy by
> > devm_usb_get_phy(). It depends on which usb phy driver is initialized
> > firstly, the usb_phy_generic or the native/real usb phy driver.
> 
> why are you initializing generic PHY if you have a real PHY ?

we have two kind of usb hosts: the native usb hosts which can be probed via. DT
and the usb hosts from pci-dwc3. The former has real phy and the latter doesn't.

> 
> > Before all old USB phy library usage removed, the solution I can have
> > is to add DWC3_SKIP_USB3PHY and DWC3_SKIP_USB2_PHY quirks and set them
> > in dwc3-pci.
> > Could such modification can be accepted? If not, could you please give
> > alternative suggestions?
> 
> we will not accept a quirk to skip PHYs, sorry. A better way of handling
> this needs to be found.
> 

OK, Got your points. It seems we need to deprecate old usb phy library usage
early.

Thanks,
Jisheng
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] tty: serial: msm_serial: Remove duplicate code in msm_console_setup

[Pramod Gurav]

Hi Stephen,

On Friday 09 January 2015 03:16 AM, Stephen Boyd wrote:
> On 01/08/2015 01:15 AM, Pramod Gurav wrote:
>>  drivers/tty/serial/msm_serial.c |   15 ---
>>  1 file changed, 15 deletions(-)
>>
>> diff --git a/drivers/tty/serial/msm_serial.c 
>> b/drivers/tty/serial/msm_serial.c
>> index c88b522..057008d 100644
>> --- a/drivers/tty/serial/msm_serial.c
>> +++ b/drivers/tty/serial/msm_serial.c
>> @@ -932,27 +932,12 @@ static int __init msm_console_setup(struct console 
>> *co, char *options)
>>  if (unlikely(!port->membase))
>>  return -ENXIO;
>>  
>> -msm_init_clock(port);
>> -
> 
> Hm.. doesn't the console setup happen before the port is opened though?
> I would think that we need to keep this around so that the clock is
> actually enabled before we go and write to hardware registers.
Thanks. Verified this. Will undo this change.

> 
>>  if (options)
>>  uart_parse_options(options, , , , );
>>  
>>  bits = 8;
>>  parity = 'n';
>>  flow = 'n';
> 
> I wonder if we should leave this here? Maybe we can rely on the user
> specifying the right values on the command line?

Ok. Will do.
> 
>> -msm_write(port, UART_MR2_BITS_PER_CHAR_8 | UART_MR2_STOP_BIT_LEN_ONE,
>> -  UART_MR2);/* 8N1 */
>> -
>> -if (baud < 300 || baud > 115200)
>> -baud = 115200;
>> -msm_set_baud_rate(port, baud);
>> -
>> -msm_reset(port);
>> -
>> -if (msm_port->is_uartdm) {
> 
> msm_port is unused now. Please remove it in the same patch.
Sure. Thanks.
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [RFC] mmc:change mmc_init workqueue into a freezable workqueue

[Wang, Yalin]

> -Original Message-
> From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk]
> Sent: Thursday, January 08, 2015 7:42 PM
> To: Wang, Yalin
> Cc: 'ch...@printf.net'; 'ulf.hans...@linaro.org'; 'tim.kry...@gmail.com';
> 'tgih@samsung.com'; 'johan.rudh...@axis.com'; 'linux-
> m...@vger.kernel.org'; 'linux-kernel@vger.kernel.org'; 'linux-arm-
> ker...@lists.infradead.org'
> Subject: Re: [RFC] mmc:change mmc_init workqueue into a freezable workqueue
> 
> On Thu, Jan 08, 2015 at 06:06:32PM +0800, Wang, Yalin wrote:
> > This patch fix the mmc driver suspend/resume conflict problems, mmc
> > workqueue will queue mmc_rescan(), and it will call some
> > pm_runtime_* functions, this will conflict with suspend path
> > sometimes, and will result in some strange behavior:
> >
> > Suspend path:
> > -000 |context_switch(inline)
> > -000 |__schedule()
> > -001 |schedule_preempt_disabled()
> > -002 |spin_lock(inline)
> > -002 |__mutex_lock_common(inline)
> > -002 |__mutex_lock_slowpath(lock_count = 0xEDCD0F48)
> > -003 |__mutex_fastpath_lock(inline)
> > -003 |mutex_lock(lock = 0xEDCD0F48)
> > -004 |sdhci_do_set_ios(host = 0xEDCD0CC0, ios = 0xEDCD0A70)
> > -005 |sdhci_set_ios(?, ios = 0xEDCD0A70)
> > -006 |mmc_set_ios(host = 0xEDCD0800)
> > -007 |mmc_delay(inline)
> > -007 |mmc_power_off(host = 0xEDCD0800)
> > -008 |mmc_suspend_host(inline)
> > -008 |mmc_suspend_host(host = 0xEDCD0800)
> > -009 |mmc_host_suspend(dev = 0xEDCD0808)
> > -010 |dpm_run_callback(cb = 0xC0627A88, dev = 0xEDCD0808, state =
> (event = 2), info = 0xC0B6EF9B)
> > -011 |__device_suspend(dev = 0xEDCD0808, state = (event = 2), ?)
> > -012 |device_suspend(inline)
> 
> Suspend can't complete until device_suspend() returns.  Hence,
> mmc_power_off() must finish.
> 
> > mmc_rescan() resume path:
> >  -000 |context_switch(inline)
> >  -000 |__schedule()
> >  -001 |do_undefinstr(regs = 0xD12242F0)
> >  -002 |__und_svc(asm)
> >   --> |exception
> 
> I assume this is what you mean by "strange behaviour" ?  If so, please give
> the full oops.  Have you fully diagnosed the failure?
> 
> > most mmc power callback function don't check this special case, and
> > will cause problems, make sure the workqueue is stopped during suspend
> > is more safe.
> 
> I think there's a bad side effect of this: if you have swap on a SD card,
> and you ask the system to hibernate, you don't want this thread to freeze.
> 
> What you do need to do is to ensure that new requests can't be processed
> while the host is suspended.
> 
> A hibernate works (approximately) as:
> 
> - freeze all tasks
> - push as much out to swap as possible
> - suspend devices
> - create system snapshot
> - resume devices
> - write system snapshot to swap
> - power down
> 
> If the MMC thread is frozen, and you have swap on SD, then it can't write
> the image to swap.
> 
I see your concerns, thanks for your comment.
I will think about some other solutions for this problems.


Thank you

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

linux-next: Tree for Jan 9

[Stephen Rothwell]

Hi all,

Changes since 20150108:

The drm-intel tree gained a conflict against the drm-intel-fixes tree.

Non-merge commits (relative to Linus' tree): 1880
 1970 files changed, 54585 insertions(+), 33090 deletions(-)



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

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

Below is a summary of the state of the merge.

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

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

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

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

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

$ git checkout master
$ git reset --hard stable
Merging origin/master (11c8f01b423b Merge branch 'rc-fixes' of 
git://git.kernel.org/pub/scm/linux/kernel/git/mmarek/kbuild)
Merging fixes/master (b94d525e58dc Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net)
Merging kbuild-current/rc-fixes (a16c5f99a28c kbuild: Fix removal of the 
debian/ directory)
Merging arc-current/for-curr (2ce7598c9a45 Linux 3.17-rc4)
Merging arm-current/fixes (3f4aa45ceea5 ARM: 8226/1: cacheflush: get rid of 
restarting block)
Merging m68k-current/for-linus (f0b99a643e96 m68k/mm: Eliminate memset after 
alloc_bootmem_pages)
Merging metag-fixes/fixes (ffe6902b66aa asm-generic: remove _STK_LIM_MAX)
Merging mips-fixes/mips-fixes (1795cd9b3a91 Linux 3.16-rc5)
Merging powerpc-merge/merge (31345e1a071e powerpc/pci: Remove unused 
force_32bit_msi quirk)
Merging powerpc-merge-mpe/fixes (1be6f10f6f9c Revert "powerpc: Secondary CPUs 
must set cpu_callin_map after setting active and online")
Merging sparc/master (66d0f7ec9f10 sparc32: destroy_context() and switch_mm() 
needs to disable interrupts.)
Merging net/master (bdec41963890 Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net)
Merging ipsec/master (f855691975bb xfrm6: Fix the nexthdr offset in 
_decode_session6.)
Merging sound-current/for-linus (92cb46584e10 ALSA: fireworks: fix an 
endianness bug for transaction length)
Merging pci-current/for-linus (97bf6af1f928 Linux 3.19-rc1)
Merging wireless-drivers/master (c702674f99e6 Merge tag 
'iwlwifi-for-kalle-2015-01-05' of 
https://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes)
Merging driver-core.current/driver-core-linus (b7392d2247cf Linux 3.19-rc2)
Merging tty.current/tty-linus (68ed7e1c3d23 serial: fix parisc boot hang)
Merging usb.current/usb-linus (b3ee8bdcd243 Merge tag 'fixes-for-v3.19-rc2' of 
git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb into usb-linus)
Merging usb-gadget-fixes/fixes (6785a1034461 usb: gadget: udc: atmel: fix 
possible IN hang issue)
Merging usb-serial-fixes/usb-linus (d80c0d141835 USB: qcserial/option: make AT 
URCs work for Sierra Wireless MC73xx)
Merging staging.current/staging-linus (b7392d2247cf Linux 3.19-rc2)
Merging char-misc.current/char-misc-linus (b7392d2247cf Linux 3.19-rc2)
Merging input-current/for-linus (9333caeaeae4 Input: I8042 - add Acer Aspire 
7738 to the nomux list)
Merging md-current/for-linus (d47648fcf061 raid5: avoid finding "discard" 
stripe)
Merging crypto-current/master (0b8c960cf6de crypto: sha-mb - Add avx2_supported 
check.)
Merging ide/master (f96fe225677b Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net)
Merging dwmw2/master (5950f0803ca9 pcmcia: remove RPX board stuff)
Merging devicetree-current/devicetree/merge (094cb98179f1 of/fdt: 
memblock_reserve /memreserve/ regions in the case of partial overlap)
Merging rr-fixes/fixes (574732c73d15 param: initialize store function to NULL 
if not available.)
Merging vfio-fixes/for-linus (7c2e211f3c95 vfio-pci: Fix the check on pci 
device type in vfio_pci_probe())
Merging kselftest-fixes/fixes (f5db310d77ef selftests/vm: fix link error for 

Re: [PATCH 0/3] epoll: Add epoll_pwait1 syscall

[Josh Triplett]

On Fri, Jan 09, 2015 at 12:49:08PM +0800, Fam Zheng wrote:
> On Thu, 01/08 18:24, Andy Lutomirski wrote:
> > On Thu, Jan 8, 2015 at 5:52 PM, Fam Zheng  wrote:
> > > On Thu, 01/08 17:28, Andy Lutomirski wrote:
> > >> On Thu, Jan 8, 2015 at 5:25 PM, Fam Zheng  wrote:
> > >> > On Thu, 01/08 09:57, Andy Lutomirski wrote:
> > >> >> I'd like to see a more ambitious change, since the timer isn't the
> > >> >> only problem like this.  Specifically, I'd like a syscall that does a
> > >> >> list of epoll-related things and then waits.  The list of things could
> > >> >> include, at least:
> > >> >>
> > >> >>  - EPOLL_CTL_MOD actions: level-triggered epoll users are likely to
> > >> >> want to turn on and off their requests for events on a somewhat
> > >> >> regular basis.
> > >> >
> > >> > This sounds good to me.
> > >> >
> > >> >>
> > >> >>  - timerfd_settime actions: this allows a single syscall to wait and
> > >> >> adjust *both* monotonic and real-time wakeups.
> > >> >
> > >> > I'm not sure, doesn't this break orthogonality between epoll and 
> > >> > timerfd?
> > >>
> > >> Yes.  It's not very elegant, and more elegant ideas are welcome.
> > >
> > > What is the purpose of embedding timerfd operation here? Modifying timerfd
> > > for each poll doesn't sound a common pattern to me.
> > 
> > Setting a timeout is definitely a common pattern, hence this thread.
> > But the current timeout interface sucks, and people should really use
> > absolute time.  (My epoll software uses absolute time.)  But then
> > users need to decide whether to have their timeout based on the
> > monotonic clock or the realtime clock (or something else entirely).
> > Some bigger programs may want both -- they may have internal events
> > queued for certain times and for certain timeouts, and those should
> > use realtime and monotonic respectively.  Heck, users may also want
> > separate slack values on those.
> > 
> > Timerfd is the only thing we have right now that is anywhere near
> > flexible enough.  Obviously if epoll became fancy enough, then we
> > could do away with the timerfd entirely here.
> > 
> > >
> > >>
> > >> >
> > >> >>
> > >> >> Would this make sense?  It could look like:
> > >> >>
> > >> >> int epoll_mod_and_pwait(int epfd,
> > >> >>   struct epoll_event *events, int maxevents,
> > >> >>   struct epoll_command *commands, int ncommands,
> > >> >>   const sigset_t *sigmask);
> > >> >
> > >> > What about flags?
> > >> >
> > >>
> > >> No room.  Maybe it should just be a struct for everything instead of
> > >> separate args.
> > >
> > > Also no room for timeout. A single struct sounds the only way to go.
> > 
> > That's what timerfd is for.  I think it would be a bit weird to
> > support "timeout" and detailed timerfd control.
> 
> I see what you mean. Thanks.
> 
> I still don't like hooking timerfd in the interface. Besides the unclean
> interface, it also feels cubersome and overkill to let users setup and add a
> dedicated timerfd to implement timeout.
> 
> How about this:
> 
> int epoll_mod_wait(int epfd, struct epoll_mod_wait_data *data);
> 
> struct epoll_mod_wait_data {
>   struct epoll_event *events;
>   int maxevents;
>   struct epoll_mod_cmd {
>   int op,
>   int fd;
>   void *data;
>   } *cmds;
>   int ncmds;
>   int flags;
>   sigset_t *sigmask;
> };
> 
> Commands ops are:
> 
>   EPOLL_CTL_ADD
>   @fd is the fd to modify; @data is epoll_event.
>   EPOLL_CTL_MOD
>   @fd is the fd to modify; @data is epoll_event.
>   EPOLL_CTL_DEL
>   @fd is the fd to modify; @data is epoll_event.
> 
>   EPOLL_CTL_SET_TIMEOUT
>   @fd is ignored, @data is timespec.
>   Clock type and relative/absolute are selected by flags as below.
> 
> Flags are given to override timeout defaults:
>   EPOLL_FL_MONOTONIC_CLOCK
>   If set, don't use realtime clock, use monotonic clock.
>   EPOLL_FL_ABSOLUTE_TIMEOUT
>   If set, don't use relative timeout, use absolute timeout.

I'd suggest using an "int clockid" field instead, like timerfd_settime;
even if it only accepts CLOCK_REALTIME and CLOCK_MONOTONIC, if it needs
extending in the future, it'd be painful to have to remap new CLOCK_*
constants into the EPOLL_FL_* namespace.  (I do think dropping timeouts
in favor of timerfds makes things more nicely orthogonal, but epoll_wait
already has a timeout parameter, so *shrug*.)

Also, I think that structure has too many levels of indirection; it'd
produce many unnecessary cache misses; considering you're trying to
eliminate the overhead of one or two extra syscalls, you don't want to
introduce a pile of unnecessary cache misses in the processes.  I'd
suggest inlining cmds as an array at the end of the structure, and
turning "void *data" into an inline epoll_event.  (Or, you could use
"events" as an in/out parameter.)

You could drop EPOLL_CTL_SET_TIMEOUT, and just include a clockid 

Re: [RFC 4/8] ARM64: Add instruction_pointer_set function

[Pratyush Anand]

On Thursday 08 January 2015 10:29 PM, Will Deacon wrote:

On Wed, Dec 31, 2014 at 03:21:20PM +, Pratyush Anand wrote:

instruction_pointer_set is needed for uprobe implementation. Hence
define it for ARM64.

Signed-off-by: Pratyush Anand 
---
  arch/arm64/include/asm/ptrace.h | 6 ++
  1 file changed, 6 insertions(+)

diff --git a/arch/arm64/include/asm/ptrace.h b/arch/arm64/include/asm/ptrace.h
index 24cc048ac3e7..29d9bf5e3635 100644
--- a/arch/arm64/include/asm/ptrace.h
+++ b/arch/arm64/include/asm/ptrace.h
@@ -206,6 +206,12 @@ static inline int valid_user_regs(struct user_pt_regs 
*regs)
  #define instruction_pointer(regs) ((regs)->pc)
  #define stack_pointer(regs)   ((regs)->sp)

+static inline void instruction_pointer_set(struct pt_regs *regs,
+  unsigned long val)
+{
+   instruction_pointer(regs) = val;
+}


Do you think we could make use of the asm-generic ptrace header to get
this for free? afaict, we just need to implement GET_USP and possibly
GET_FP for the compat case (although it may well be that we still handle
the compat case entirely separately).



Yes, We can use asm-generic for it.

I think , we can also add link_pointer and link_pointer_set in 
asm-generic/ptrace.h to help with all retprobes.


~Pratyush

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


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

RE: [PATCH net-next 07/11] r8169:update rtl8168f pcie ephy parameter

[Hau]

> -Original Message-
> From: David Miller [mailto:da...@davemloft.net]
> Sent: Friday, January 09, 2015 12:09 PM
> To: david.lai...@aculab.com
> Cc: Hau; net...@vger.kernel.org; nic_swsd; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH net-next 07/11] r8169:update rtl8168f pcie ephy
> parameter
> 
> From: David Laight 
> Date: Wed, 7 Jan 2015 16:45:58 +
> 
> > From: Chunhao Lin
> >> @@ -5852,7 +5852,9 @@ static void rtl_hw_start_8168f_1(struct
> rtl8169_private *tp)
> >>{ 0x06, 0x00c0, 0x0020 },
> >>{ 0x08, 0x0001, 0x0002 },
> >>{ 0x09, 0x, 0x0080 },
> >> -  { 0x19, 0x, 0x0224 }
> >> +  { 0x19, 0x, 0x0224 },
> >> +  { 0x00, 0x, 0x0008 },
> >> +  { 0x0c, 0x3df0, 0x0200 }
> >
> > I can't help feeling these lines all require short comments.
> 
> Agreed.
> 
> And this goes for some of the other patches that look like this too.
>
I will merge the patches and update again.

Thanks.
 
--Please consider the environment before printing this e-mail.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] serial: 8250: Make ISA ports optional

[Peter Hurley]

On 01/08/2015 05:05 PM, Arnd Bergmann wrote:
> On Thursday 08 January 2015 11:11:51 Peter Hurley wrote:
>>
>> This interface is just storage and minor allocation, since the
>> port-reuse behavior will be limited to the "universal" driver.
>> From a sub-driver perspective, the shared storage is actually
>> a hindrance, so that reduces the requirement to minor allocation.
>>
>> And that's where I'm stuck at the moment -- how to share ttyS
>> minor allocation. ttyS console is a related problem.
> 
> One idea that has come up in the past but never saw an implementation
> is to make the ttyS namespace and minor numbers completely generic and
> let any serial port driver use it. This would be a major rework, but
> have the added advantage of cleaning up a number of other namespace
> issues as well. There also lots of open question, in particular how
> to maintain compatibility with existing drivers. One could imagine
> that each uart always gets a ttyS device and optionally also gets
> a device node for the same port with a driver specific chardev as
> most of them do today. Or it could be an either/or decision that is
> made at compile time or as a module parameter.

I'm not totally convinced that sharing minor allocation is the right
solution. ISTM that the main goal is for at least one serial driver
to represent ttyS (assuming that it is a suitable work-alike to the
8250 driver) while other ttyS serial drivers must still be able to
load and operate.

So for example, a UART that is ttyS in a typical configuration, might
be ttyX when another driver has been configured as ttyS instead.
Assuming that every uart driver has a unique, alternate base name,
then the problem is reduced to selecting the appropriate driver for
ttyS.

Some use cases would require selecting the ttyS driver at build time.
Others would probably require the notion of a preferred driver.

What got me thinking about this approach instead of sharing minor
allocation was based on the 'first-come, first-served' question
I asked back in Dec. What happens when probe order varies and
console=ttyS0/login prompt doesn't show up where it's supposed to?
I've had this experience with multiple ethernet adapters and it's
not fun.

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

[net-next:master 62/63] drivers/scsi/csiostor/csio_hw.c:2012:5: sparse: symbol 'csio_hw_prep_fw' was not declared. Should it be static?

[kbuild test robot]

tree:   git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git master
head:   fb57720daf6e56ba453414b5e8dd9cb3c0c80257
commit: f40e74ffa3de44f7ef4c09653b070dd115ab7fbe [62/63] csiostor:firmware 
upgrade fix
reproduce:
  # apt-get install sparse
  git checkout f40e74ffa3de44f7ef4c09653b070dd115ab7fbe
  make ARCH=x86_64 allmodconfig
  make C=1 CF=-D__CHECK_ENDIAN__


sparse warnings: (new ones prefixed by >>)

   drivers/scsi/csiostor/csio_hw.c:259:17: sparse: cast to restricted __le32
   drivers/scsi/csiostor/csio_hw.c:536:31: sparse: incorrect type in assignment 
(different base types)
   drivers/scsi/csiostor/csio_hw.c:536:31:expected unsigned int [unsigned] 
[usertype] 
   drivers/scsi/csiostor/csio_hw.c:536:31:got restricted __be32 [usertype] 

>> drivers/scsi/csiostor/csio_hw.c:2012:5: sparse: symbol 'csio_hw_prep_fw' was 
>> not declared. Should it be static?

Please review and possibly fold the followup patch.

---
0-DAY kernel test infrastructureOpen Source Technology Center
http://lists.01.org/mailman/listinfo/kbuild Intel Corporation
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/3] epoll: Add epoll_pwait1 syscall

[Fam Zheng]

On Thu, 01/08 18:24, Andy Lutomirski wrote:
> On Thu, Jan 8, 2015 at 5:52 PM, Fam Zheng  wrote:
> > On Thu, 01/08 17:28, Andy Lutomirski wrote:
> >> On Thu, Jan 8, 2015 at 5:25 PM, Fam Zheng  wrote:
> >> > On Thu, 01/08 09:57, Andy Lutomirski wrote:
> >> >> I'd like to see a more ambitious change, since the timer isn't the
> >> >> only problem like this.  Specifically, I'd like a syscall that does a
> >> >> list of epoll-related things and then waits.  The list of things could
> >> >> include, at least:
> >> >>
> >> >>  - EPOLL_CTL_MOD actions: level-triggered epoll users are likely to
> >> >> want to turn on and off their requests for events on a somewhat
> >> >> regular basis.
> >> >
> >> > This sounds good to me.
> >> >
> >> >>
> >> >>  - timerfd_settime actions: this allows a single syscall to wait and
> >> >> adjust *both* monotonic and real-time wakeups.
> >> >
> >> > I'm not sure, doesn't this break orthogonality between epoll and timerfd?
> >>
> >> Yes.  It's not very elegant, and more elegant ideas are welcome.
> >
> > What is the purpose of embedding timerfd operation here? Modifying timerfd
> > for each poll doesn't sound a common pattern to me.
> 
> Setting a timeout is definitely a common pattern, hence this thread.
> But the current timeout interface sucks, and people should really use
> absolute time.  (My epoll software uses absolute time.)  But then
> users need to decide whether to have their timeout based on the
> monotonic clock or the realtime clock (or something else entirely).
> Some bigger programs may want both -- they may have internal events
> queued for certain times and for certain timeouts, and those should
> use realtime and monotonic respectively.  Heck, users may also want
> separate slack values on those.
> 
> Timerfd is the only thing we have right now that is anywhere near
> flexible enough.  Obviously if epoll became fancy enough, then we
> could do away with the timerfd entirely here.
> 
> >
> >>
> >> >
> >> >>
> >> >> Would this make sense?  It could look like:
> >> >>
> >> >> int epoll_mod_and_pwait(int epfd,
> >> >>   struct epoll_event *events, int maxevents,
> >> >>   struct epoll_command *commands, int ncommands,
> >> >>   const sigset_t *sigmask);
> >> >
> >> > What about flags?
> >> >
> >>
> >> No room.  Maybe it should just be a struct for everything instead of
> >> separate args.
> >
> > Also no room for timeout. A single struct sounds the only way to go.
> 
> That's what timerfd is for.  I think it would be a bit weird to
> support "timeout" and detailed timerfd control.

I see what you mean. Thanks.

I still don't like hooking timerfd in the interface. Besides the unclean
interface, it also feels cubersome and overkill to let users setup and add a
dedicated timerfd to implement timeout.

How about this:

int epoll_mod_wait(int epfd, struct epoll_mod_wait_data *data);

struct epoll_mod_wait_data {
struct epoll_event *events;
int maxevents;
struct epoll_mod_cmd {
int op,
int fd;
void *data;
} *cmds;
int ncmds;
int flags;
sigset_t *sigmask;
};

Commands ops are:

EPOLL_CTL_ADD
@fd is the fd to modify; @data is epoll_event.
EPOLL_CTL_MOD
@fd is the fd to modify; @data is epoll_event.
EPOLL_CTL_DEL
@fd is the fd to modify; @data is epoll_event.

EPOLL_CTL_SET_TIMEOUT
@fd is ignored, @data is timespec.
Clock type and relative/absolute are selected by flags as below.

Flags are given to override timeout defaults:
EPOLL_FL_MONOTONIC_CLOCK
If set, don't use realtime clock, use monotonic clock.
EPOLL_FL_ABSOLUTE_TIMEOUT
If set, don't use relative timeout, use absolute timeout.

Thanks,
Fam
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] (gpio-fan): Add thermal control hooks

[Guenter Roeck]

On 01/08/2015 10:05 AM, Nishanth Menon wrote:

Allow gpio-fan to be used as thermal cooling device for platforms that
use GPIO maps to control fans.

As part of this change, we make the shutdown and remove logic the same
as well.

Signed-off-by: Nishanth Menon 
---


Applied to -next.

Thanks,
Guenter

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

Re: [PATCH 2/2] platform/x86: Add Intel Galileo platform specific setup

[Darren Hart]

On Mon, Dec 29, 2014 at 05:23:03PM +, Bryan O'Donoghue wrote:

Hi Bryan,

Good discussion from Andy and Boon Leong, I'll try not to duplicate their review
here.

> Intel Galileo Gen1 and Gen2 boot to Linux from EFI and grub with IMR
> registers enabled around the compressed kernel image and boot params data
> structure.
> 
> The purpose of the IMRs around the compressed kernel and boot params data
> structure is to ensure that no spurious data writes from any agent within
> the Quark system can corrupt the kernel/boot-params data during boot.
> 
> The kernel needs to tear-down the IMRs placed around the compressed kernel
> image and boot-params data structure since the EFI memory map marks the two
> regions of memory as usable memory and the kernel will happily reuse these
> memory regions. Without tearing down the boot-time IMRs drivers run the
> significant risk of violating one of the stale IMRs since dma_alloc_coherent
> can hand addresses to DMA capable south cluster peripherals such as the SD,
> Ethernet, USB host/device, which will then cause an IMR access violation
> when a DMA read/write occurs to the address ranges in question.
> 
> Since the Quark EFI bringup code configures the system to reset on an IMR
> violation, this means that common operations such as mouting an SD based
> root filesystem, communicating with a USB device or sending Ethernet traffic
> can cause an immediate system reset.
> 
> IMR usage during system boot on Galileo is detailed in
> Quark_SecureBoot_PRM_330234_001.pdf. This document details each IMR used
> during the boot process and the data being protected by that IMR. The kernel
> needs tidy-up IMRs used during the boot process to ensure an IMR violation
> doesn't cause a system reset.

does not

(generally speaking, please avoid contractions in documentation)

> 
> This platform code does two things.
> 
> Firstly it tears down the boot-time IMRs used to protect the compressed

First, 

> kernel image and boot params data structure.
> 
> Secondly it sets up an IMR around the kernel's text section from &_sinittext

Second, 

> - &_text ensuring that on the CPU in non-SMM mode can read/write this
> address range. A spurious DMA write to the kernel's .text section will
> then cause an IMR violation and system reset, consistent with the current
> Galileo BSP behaviour.
> 
> Signed-off-by: Bryan O'Donoghue 
> ---
>  drivers/platform/x86/Kconfig |  15 +++
>  drivers/platform/x86/Makefile|   1 +
>  drivers/platform/x86/intel_galileo.c | 175 
> +++
>  3 files changed, 191 insertions(+)
>  create mode 100644 drivers/platform/x86/intel_galileo.c
> 
> diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig
> index 638e7970..e384dcd 100644
> --- a/drivers/platform/x86/Kconfig
> +++ b/drivers/platform/x86/Kconfig
> @@ -804,6 +804,21 @@ config INTEL_OAKTRAIL
> enable/disable the Camera, WiFi, BT etc. devices. If in doubt, say Y
> here; it will only load on supported platforms.
>  
> +config INTEL_GALILEO
> + bool "Intel Galileo Platform Support"
> + depends on X86_32 && PCI
> + select IOSF_MBI
> + select IMR
> + ---help---
> +   Intel Galileo platform support. This code is used to tear-down
> +   BIOS and Grub Isolated Memory Regions used during bootup.
> +   This sanitises the IMR memory map to agree with the EFI/e820
> +   memory map, without this code your IMR memory map will conflict
> +   with the EFI memory map and it's highly likely DMA accesses initiated

it is

> +   by Ethernet, SD and/or USB will result in a system reset.
> +
> +   If in doubt, say Y here, the code will only run on a Galileo Gen1/Gen2
> +
>  config SAMSUNG_Q10
>   tristate "Samsung Q10 Extras"
>   depends on ACPI
> diff --git a/drivers/platform/x86/Makefile b/drivers/platform/x86/Makefile
> index f82232b..a0c013d 100644
> --- a/drivers/platform/x86/Makefile
> +++ b/drivers/platform/x86/Makefile
> @@ -51,6 +51,7 @@ obj-$(CONFIG_SAMSUNG_LAPTOP)+= samsung-laptop.o
>  obj-$(CONFIG_MXM_WMI)+= mxm-wmi.o
>  obj-$(CONFIG_INTEL_MID_POWER_BUTTON) += intel_mid_powerbtn.o
>  obj-$(CONFIG_INTEL_OAKTRAIL) += intel_oaktrail.o
> +obj-$(CONFIG_INTEL_GALILEO)  += intel_galileo.o
>  obj-$(CONFIG_SAMSUNG_Q10)+= samsung-q10.o
>  obj-$(CONFIG_APPLE_GMUX) += apple-gmux.o
>  obj-$(CONFIG_INTEL_RST)  += intel-rst.o
> diff --git a/drivers/platform/x86/intel_galileo.c 
> b/drivers/platform/x86/intel_galileo.c
> new file mode 100644
> index 000..2a555aa
> --- /dev/null
> +++ b/drivers/platform/x86/intel_galileo.c
> @@ -0,0 +1,175 @@
> +/*
> + * intel_galileo.c - Intel Galileo platform support.
> + *
> + * Copyright(c) 2013 Intel Corporation.
> + * Copyright(c) 2014 Bryan O'Donoghue 
> + *
> + * This platform code provides an entry point to do Galileo specific
> + * setup. Critically IMRs are policed to ensure the EFI provided memory
> + * map 

Re: [Patch v2 1/2] dmaengine: Add ADM driver

[Archit Taneja]

Hi,

On 01/08/2015 08:56 AM, Andy Gross wrote:

Signed-off-by: Andy Gross 




+static struct dma_async_tx_descriptor *adm_prep_slave_sg(struct dma_chan *chan,
+   struct scatterlist *sgl, unsigned int sg_len,
+   enum dma_transfer_direction direction, unsigned long flags,
+   void *context)
+{
+   struct adm_chan *achan = to_adm_chan(chan);
+   struct adm_device *adev = achan->adev;
+   struct adm_async_desc *async_desc;
+   struct scatterlist *sg;
+   u32 i;
+   u32 single_count = 0, box_count = 0, desc_offset = 0, crci = 0;
+   struct adm_desc_hw_box *box_desc;
+   struct adm_desc_hw_single *single_desc;
+   void *desc;
+   u32 *cple, *last_cmd;
+   u32 burst;
+   int blk_size = -EINVAL;


blk_size should be set to 0 here. Otherwise async_desc->blk_size takes 
-EINVAL when no flow control.



+
+
+   if (!is_slave_direction(direction)) {
+   dev_err(adev->dev, "invalid dma direction\n");
+   return NULL;
+   }
+
+   /*
+* get burst value from slave configuration
+* If zero, default to maximum burst size
+* If larger than the max transfer size, set to ADM_MAX_XFER
+*/
+   burst = (direction == DMA_MEM_TO_DEV) ?
+   achan->slave.dst_maxburst :
+   achan->slave.src_maxburst;
+
+   if (!burst || burst > ADM_MAX_XFER)
+   burst = ADM_MAX_XFER;
+
+   /* if using flow control, validate burst and crci values */
+   if (achan->slave.device_fc) {
+
+   blk_size = adm_get_blksize(burst);
+   if (blk_size < 0) {
+   dev_err(adev->dev, "invalid burst value w/ crci: %d\n",
+   burst);
+   return ERR_PTR(-EINVAL);
+   }
+
+   crci = achan->slave.slave_id;
+   if (!(crci & 0xf)) {


This check isn't sufficient for the crci to lie between 1 and 15. 
slave_id passed as, say, 0xf5, will be valid.






+/**
+ * adm_dma_irq - irq handler for ADM controller
+ * @irq: IRQ of interrupt
+ * @data: callback data
+ *
+ * IRQ handler for the bam controller
+ */
+static irqreturn_t adm_dma_irq(int irq, void *data)
+{
+   struct adm_device *adev = data;
+   u32 srcs, i;
+   struct adm_async_desc *async_desc;
+   unsigned long flags;
+
+   srcs = readl_relaxed(adev->regs +
+   HI_SEC_DOMAIN_IRQ_STATUS(adev->ee));
+
+   for (i = 0; i < 16; i++) {


we could use adev->num_channels here instead of 16.


+   struct adm_chan *achan = >channels[i];
+   u32 status, result;
+
+   if (srcs & BIT(i)) {
+   status = readl_relaxed(adev->regs +
+   HI_CH_STATUS_SD(i, adev->ee));
+
+   /* if no result present, skip */
+   if (!(status & CH_STATUS_VALID))
+   continue;
+
+   result = readl_relaxed(adev->regs +
+   HI_CH_RSLT(i, adev->ee));
+
+   /* no valid results, skip */
+   if (!(result & CH_RSLT_VALID))
+   continue;
+
+   /* flag error if transaction was flushed or failed */
+   if (result & (CH_RSLT_ERR | CH_RSLT_FLUSH))
+   achan->error = 1;
+
+   spin_lock_irqsave(>vc.lock, flags);
+   async_desc = achan->curr_txd;
+
+   achan->curr_txd = NULL;
+
+   if (async_desc) {
+   vchan_cookie_complete(_desc->vd);
+
+   /* kick off next DMA */
+   adm_start_dma(achan);
+   }
+
+   spin_unlock_irqrestore(>vc.lock, flags);
+   }
+   }
+
+   return IRQ_HANDLED;
+}





+
+static int adm_dma_probe(struct platform_device *pdev)
+{
+   struct adm_device *adev;
+   struct resource *iores;
+   int ret;
+   u32 i;
+
+   adev = devm_kzalloc(>dev, sizeof(*adev), GFP_KERNEL);
+   if (!adev)
+   return -ENOMEM;
+
+   adev->dev = >dev;
+
+   iores = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+   adev->regs = devm_ioremap_resource(>dev, iores);
+   if (IS_ERR(adev->regs))
+   return PTR_ERR(adev->regs);
+
+   adev->irq = platform_get_irq(pdev, 0);
+   if (adev->irq < 0)
+   return adev->irq;
+
+   ret = of_property_read_u32(pdev->dev.of_node, "qcom,ee", >ee);
+   if (ret) {
+   dev_err(adev->dev, "Execution environment unspecified\n");
+   return ret;
+   }
+
+   adev->core_clk = devm_clk_get(adev->dev, "core");
+   if (IS_ERR(adev->core_clk))
+   return PTR_ERR(adev->core_clk);
+
+   ret = 

Re: [PATCH v5][resend v4] of: replace Asahi Kasei Corp vendor prefix

[Stephen Warren]

On 01/08/2015 08:40 PM, Kuninori Morimoto wrote:
> 
> Hi Stephen, Olof, Arnd, Rob, Andrew
> 
> I'm sending this "of: replace Asahi Kasei Corp vendor prefix" during
> half-year (since Jun 2014) , many times. But, no-one care it.
> I don't know who is the best maintainer.
>  - Stephen : because it has Tegra ?
>  - Olof: because it has Tegra (= ARM) ?
>  - Arnd: because it has Tegra (= ARM) ?
>  - Matthias: because it has Tegra (= ARM SoC) ?
>  - Rob : because DT ?
>  - Andrew  : Last chance ?
> 
> But, could you please care this patch ?
> I will re-send it again

It doesn't seem to be ack'd by any of the DT maintainers. Retro-actively
changing a DT vendor name would need that, I think.

Thierry and Alex (both Tegra maintainers) appear to have ack'd it, so it
seems they expect it to go through some tree other than Tegra. Weren't
there a bunch of related patches along with this (e.g. updating relevant
drivers to support both prefixes?) so it was expected this patch would
be applied together with them?

>> From: Kuninori Morimoto 
>>
>> Current vendor-prefixes.txt already has "ak" prefix for Asahi Kasei Corp
>> by ae8c4209af2c(of: Add vendor prefix for Asahi Kasei Corp.)
>>
>> It went through the appropriate review process. But, almost all
>> Asahi Kasei chip drivers are using "asahi-kasei" prefix today.
>> (arch/arm/boot/dts/tegra20-seaboard.dts only is using "ak,ak8975",
>>  but there are instances of "asahi-kasei,ak8975" in other dts files.
>>  And drivers/iio/magnetometer/ak8975.c doesn't support "ak,ak8975" prefix)
>> So, we made a mistake there.
>>
>> In addition, checkpatch.pl reports WARNING if it is using "asahi-kasei"
>> prerfix in DT file.
>> (DT compatible string vendor "asahi-kasei" appears un-documented)
>>
>> Marking it deprecated and warning with checkpatch is certainly
>> preferable. So, this patch replace "ak" to "asahi-kasei" in
>> vendor-prefixes.txt. (and fixup tegra20-seaboard)
>>
>> OTOH, Asahi Kasei is usually referred to as "AKM", but this patch
>> doesn't care about it. Because no DT is using that today.
>>
>> Signed-off-by: Kuninori Morimoto 
>> Acked-by: Thierry Reding 
>> Acked-by: Alexandre Courbot 

>> diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt 
>> b/Documentation/devicetree/bindings/vendor-prefixes.txt

>> -ak  Asahi Kasei Corp.

>> +asahi-kasei Asahi Kasei Corp.

>> diff --git a/arch/arm/boot/dts/tegra20-seaboard.dts 
>> b/arch/arm/boot/dts/tegra20-seaboard.dts

>>  magnetometer@c {
>> -compatible = "ak,ak8975";
>> +compatible = "asahi-kasei,ak8975";

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] hwmon: (ina2xx) implement update_interval attribute for ina226

[Guenter Roeck]

On 01/08/2015 10:14 AM, Bartosz Golaszewski wrote:

2015-01-08 18:05 GMT+01:00 Guenter Roeck :

What is the purpose of multiplying the calculated average by 2 ?


The comment above says:


+ /*
+  * Add bus and shunt voltage conversion times and multiple them
+  * by the averaging rate. Return the result in milliseconds.
+  */


Since both conversion times are the same and equal
INA226_CONV_TIME_DEFAULT I just multiplied it by 2 - I thought it was
clear enough. I'll fix that in the next iteration.



Sorry, still don't get it. I must be a bit slow today ;-)

Guenter


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

[patch 2/2] mm: memcontrol: default hierarchy interface for memory

[Johannes Weiner]

Introduce the basic control files to account, partition, and limit
memory using cgroups in default hierarchy mode.

This interface versioning allows us to address fundamental design
issues in the existing memory cgroup interface, further explained
below.  The old interface will be maintained indefinitely, but a
clearer model and improved workload performance should encourage
existing users to switch over to the new one eventually.

The control files are thus:

  - memory.current shows the current consumption of the cgroup and its
descendants, in bytes.

  - memory.low configures the lower end of the cgroup's expected
memory consumption range.  The kernel considers memory below that
boundary to be a reserve - the minimum that the workload needs in
order to make forward progress - and generally avoids reclaiming
it, unless there is an imminent risk of entering an OOM situation.

  - memory.high configures the upper end of the cgroup's expected
memory consumption range.  A cgroup whose consumption grows beyond
this threshold is forced into direct reclaim, to work off the
excess and to throttle new allocations heavily, but is generally
allowed to continue and the OOM killer is not invoked.

  - memory.max configures the hard maximum amount of memory that the
cgroup is allowed to consume before the OOM killer is invoked.

  - memory.events shows event counters that indicate how often the
cgroup was reclaimed while below memory.low, how often it was
forced to reclaim excess beyond memory.high, how often it hit
memory.max, and how often it entered OOM due to memory.max.  This
allows users to identify configuration problems when observing a
degradation in workload performance.  An overcommitted system will
have an increased rate of low boundary breaches, whereas increased
rates of high limit breaches, maximum hits, or even OOM situations
will indicate internally overcommitted cgroups.

For existing users of memory cgroups, the following deviations from
the current interface are worth pointing out and explaining:

  - The original lower boundary, the soft limit, is defined as a limit
that is per default unset.  As a result, the set of cgroups that
global reclaim prefers is opt-in, rather than opt-out.  The costs
for optimizing these mostly negative lookups are so high that the
implementation, despite its enormous size, does not even provide
the basic desirable behavior.  First off, the soft limit has no
hierarchical meaning.  All configured groups are organized in a
global rbtree and treated like equal peers, regardless where they
are located in the hierarchy.  This makes subtree delegation
impossible.  Second, the soft limit reclaim pass is so aggressive
that it not just introduces high allocation latencies into the
system, but also impacts system performance due to overreclaim, to
the point where the feature becomes self-defeating.

The memory.low boundary on the other hand is a top-down allocated
reserve.  A cgroup enjoys reclaim protection when it and all its
ancestors are below their low boundaries, which makes delegation
of subtrees possible.  Secondly, new cgroups have no reserve per
default and in the common case most cgroups are eligible for the
preferred reclaim pass.  This allows the new low boundary to be
efficiently implemented with just a minor addition to the generic
reclaim code, without the need for out-of-band data structures and
reclaim passes.  Because the generic reclaim code considers all
cgroups except for the ones running low in the preferred first
reclaim pass, overreclaim of individual groups is eliminated as
well, resulting in much better overall workload performance.

  - The original high boundary, the hard limit, is defined as a strict
limit that can not budge, even if the OOM killer has to be called.
But this generally goes against the goal of making the most out of
the available memory.  The memory consumption of workloads varies
during runtime, and that requires users to overcommit.  But doing
that with a strict upper limit requires either a fairly accurate
prediction of the working set size or adding slack to the limit.
Since working set size estimation is hard and error prone, and
getting it wrong results in OOM kills, most users tend to err on
the side of a looser limit and end up wasting precious resources.

The memory.high boundary on the other hand can be set much more
conservatively.  When hit, it throttles allocations by forcing
them into direct reclaim to work off the excess, but it never
invokes the OOM killer.  As a result, a high boundary that is
chosen too aggressively will not terminate the processes, but
instead it will lead to gradual performance degradation.  The user
can monitor this and make corrections until the minimal memory

[patch 1/2] mm: page_counter: pull "-1" handling out of page_counter_memparse()

[Johannes Weiner]

It was convenient to have the generic function handle it, as all
callsites agreed.  Subsequent patches will add new user interfaces
that do not want to support the "-1" special string.

Signed-off-by: Johannes Weiner 
---
 mm/hugetlb_cgroup.c   | 10 +++---
 mm/memcontrol.c   | 20 ++--
 mm/page_counter.c |  6 --
 net/ipv4/tcp_memcontrol.c | 10 +++---
 4 files changed, 28 insertions(+), 18 deletions(-)

diff --git a/mm/hugetlb_cgroup.c b/mm/hugetlb_cgroup.c
index 037e1c00a5b7..ee3fc80adba1 100644
--- a/mm/hugetlb_cgroup.c
+++ b/mm/hugetlb_cgroup.c
@@ -279,9 +279,13 @@ static ssize_t hugetlb_cgroup_write(struct 
kernfs_open_file *of,
return -EINVAL;
 
buf = strstrip(buf);
-   ret = page_counter_memparse(buf, _pages);
-   if (ret)
-   return ret;
+   if (!strcmp(buf, "-1")) {
+   nr_pages = PAGE_COUNTER_MAX;
+   } else {
+   ret = page_counter_memparse(buf, _pages);
+   if (ret)
+   return ret;
+   }
 
idx = MEMFILE_IDX(of_cft(of)->private);
 
diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index 202e3862d564..20486da85750 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -3400,9 +3400,13 @@ static ssize_t mem_cgroup_write(struct kernfs_open_file 
*of,
int ret;
 
buf = strstrip(buf);
-   ret = page_counter_memparse(buf, _pages);
-   if (ret)
-   return ret;
+   if (!strcmp(buf, "-1")) {
+   nr_pages = PAGE_COUNTER_MAX;
+   } else {
+   ret = page_counter_memparse(buf, _pages);
+   if (ret)
+   return ret;
+   }
 
switch (MEMFILE_ATTR(of_cft(of)->private)) {
case RES_LIMIT:
@@ -3768,9 +3772,13 @@ static int __mem_cgroup_usage_register_event(struct 
mem_cgroup *memcg,
unsigned long usage;
int i, size, ret;
 
-   ret = page_counter_memparse(args, );
-   if (ret)
-   return ret;
+   if (!strcmp(args, "-1")) {
+   threshold = PAGE_COUNTER_MAX;
+   } else {
+   ret = page_counter_memparse(args, );
+   if (ret)
+   return ret;
+   }
 
mutex_lock(>thresholds_lock);
 
diff --git a/mm/page_counter.c b/mm/page_counter.c
index a009574fbba9..0d4f9daf68bd 100644
--- a/mm/page_counter.c
+++ b/mm/page_counter.c
@@ -173,15 +173,9 @@ int page_counter_limit(struct page_counter *counter, 
unsigned long limit)
  */
 int page_counter_memparse(const char *buf, unsigned long *nr_pages)
 {
-   char unlimited[] = "-1";
char *end;
u64 bytes;
 
-   if (!strncmp(buf, unlimited, sizeof(unlimited))) {
-   *nr_pages = PAGE_COUNTER_MAX;
-   return 0;
-   }
-
bytes = memparse(buf, );
if (*end != '\0')
return -EINVAL;
diff --git a/net/ipv4/tcp_memcontrol.c b/net/ipv4/tcp_memcontrol.c
index 272327134a1b..a9d9fcb4dc25 100644
--- a/net/ipv4/tcp_memcontrol.c
+++ b/net/ipv4/tcp_memcontrol.c
@@ -120,9 +120,13 @@ static ssize_t tcp_cgroup_write(struct kernfs_open_file 
*of,
switch (of_cft(of)->private) {
case RES_LIMIT:
/* see memcontrol.c */
-   ret = page_counter_memparse(buf, _pages);
-   if (ret)
-   break;
+   if (!strcmp(buf, "-1")) {
+   nr_pages = PAGE_COUNTER_MAX;
+   } else {
+   ret = page_counter_memparse(buf, _pages);
+   if (ret)
+   break;
+   }
mutex_lock(_limit_mutex);
ret = tcp_update_limit(memcg, nr_pages);
mutex_unlock(_limit_mutex);
-- 
2.2.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/

[BUG] drm/i915: backlight off after resume

[Jeremiah Mahler]

Jani, all,

On a Lenovo X1 Carbon if the display is off when suspend is entered
it will be off when it is resumed.  A key must be pressed to restore
normal brightness.

  xset dpms force off
  sleep 1
  sudo systemctl suspend
  (resume)
  (screen off, press any key)

The behavior I am accustomed to is for it to resume with the screen on.
All of my other machines behave this way and the X1 Carbon behaved this
way in the past.

I performed a bisect and found that the following commit introduced the
problem.

  From 6dda730e55f412a6dfb181cae6784822ba463847 Mon Sep 17 00:00:00 2001
  From: Jani Nikula 
  Date: Tue, 24 Jun 2014 18:27:40 +0300
  Subject: [PATCH] drm/i915: respect the VBT minimum backlight brightness
  
  Historically we've exposed the full backlight PWM duty cycle range to
  the userspace, in the name of "mechanism, not policy". However, it turns
  out there are both panels and board designs where there is a minimum
  duty cycle that is required for proper operation. The minimum duty cycle
  is available in the VBT.
  
  The backlight class sysfs interface does not make any promises to the
  userspace about the physical meaning of the range
  0..max_brightness. Specifically there is no guarantee that 0 means off;
  indeed for acpi_backlight 0 usually is not off, but the minimum
  acceptable value.
  
  Respect the minimum backlight, and expose the range acceptable to the
  hardware as 0..max_brightness to the userspace via the backlight class
  device; 0 means the minimum acceptable enabled value. To switch off the
  backlight, the user must disable the encoder.
  
  As a side effect, make the backlight class device max brightness and
  physical PWM modulation frequency (i.e. max duty cycle)
  independent. This allows a follow-up patch to virtualize the max value
  exposed to the userspace.
  
  Signed-off-by: Jani Nikula 
  Reviewed-by: Jesse Barnes 
  [danvet: s/BUG_ON/WARN_ON/]
  Signed-off-by: Daniel Vetter 

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

Re: [PATCH 1/2] tracing: Move enabling tracepoints to just after rcu_init()

[Wang Nan]

Hi Steven Rostedt,

During studying your code we find a problem, please see below.

> 
> From: "Steven Rostedt (Red Hat)" 
> 
> Enabling tracepoints at boot up can be very useful. The tracepoint
> can be initialized right after RCU has been. There's no need to
> wait for the early_initcall() to be called. That's too late for some
> things that can use tracepoints for debugging. Move the logic to
> enable tracepoints out of the initcalls and into init/main.c to
> right after rcu_init().
> 
> This also allows trace_printk() to be used early too.
> 
> Link: http://lkml.kernel.org/r/alpine.DEB.2.11.1412121539300.16494@nanos
> Link: http://lkml.kernel.org/r/20141214164104.307127...@goodmis.org
> 
> Reviewed-by: Paul E. McKenney 
> Suggested-by: Thomas Gleixner 
> Tested-by: Thomas Gleixner 
> Acked-by: Thomas Gleixner 
> Signed-off-by: Steven Rostedt 

[...]

> +void __init trace_init(void)
> +{
> + tracer_alloc_buffers();
> + init_ftrace_syscalls();
> + trace_event_init(); 
> +}
> +

[...]

> +
> +void __init trace_event_init(void)
> +{
> + event_trace_memsetup();
> + init_ftrace_syscalls();
> + event_trace_enable();
> +}
> +

init_ftrace_syscalls() get called twice by trace_init() and trace_event_init(), 
some resources are wasted.
At lease one of them can be removed.

In addition, could you please have a look at my early kprobe patch series?

http://lists.infradead.org/pipermail/linux-arm-kernel/2015-January/313835.html

Which enables kprobe very early, even before memory initialized. I think it is 
possible to combine these
early tracing facilities together.

Thank you!


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] net: fec: fix NULL pointer dereference in fec_enet_timeout_work

[David Miller]

From: Hubert Feurstein 
Date: Wed,  7 Jan 2015 14:48:17 +0100

> From: Hubert Feurstein 
> 
> This patch initialises the fep->netdev pointer. This pointer was not
> initialised at all, but is used in fec_enet_timeout_work and in some
> error paths.
> 
> Signed-off-by: Hubert Feurstein 

Applied.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/6] btwilink: add minimal device tree support

[Varka Bhadram]

Hi,

On Fri, Jan 9, 2015 at 9:17 AM, Gigi Joseph  wrote:
> Add minimal device tree support to the btwilink driver that is used
> for binding bluetooth with the ti-st shared transport driver.
>
> Signed-off-by: Eyal Reizer 
> Signed-off-by: bvijay 
> Signed-off-by: Gigi Joseph 
> ---
>  drivers/bluetooth/btwilink.c | 11 +++
>  1 file changed, 11 insertions(+)
>
> diff --git a/drivers/bluetooth/btwilink.c b/drivers/bluetooth/btwilink.c
> index 55c135b..95adec3 100644
> --- a/drivers/bluetooth/btwilink.c
> +++ b/drivers/bluetooth/btwilink.c
> @@ -30,6 +30,7 @@
>
>  #include 
>  #include 
> +#include 
>
>  /* Bluetooth Driver Version */
>  #define VERSION   "1.0"
> @@ -286,6 +287,14 @@ static int ti_st_send_frame(struct hci_dev *hdev, struct 
> sk_buff *skb)
> return 0;
>  }
>
> +static const struct of_device_id btwilink_of_match[] = {
> +{
> +   .compatible = "btwilink",
compatible property include the manufacturer name also...
compatible=","
> +   },
> +   {}
> +};
> +MODULE_DEVICE_TABLE(of, btwilink_of_match);
> +
>  static int bt_ti_probe(struct platform_device *pdev)
>  {
> static struct ti_st *hst;
> @@ -349,6 +358,8 @@ static struct platform_driver btwilink_driver = {
> .remove = bt_ti_remove,
> .driver = {
> .name = "btwilink",
> +   .owner = THIS_MODULE,
No need to update this field. It will be updated by driver core.
> +   .of_match_table = of_match_ptr(btwilink_of_match),
> },
>  };
>
> --
> 1.9.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



-- 
Thanks and Regards,
Varka Bhadram.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 net-next 07/11] r8169:update rtl8168f pcie ephy parameter

[David Miller]

From: David Laight 
Date: Wed, 7 Jan 2015 16:45:58 +

> From: Chunhao Lin
>> @@ -5852,7 +5852,9 @@ static void rtl_hw_start_8168f_1(struct 
>> rtl8169_private *tp)
>>  { 0x06, 0x00c0, 0x0020 },
>>  { 0x08, 0x0001, 0x0002 },
>>  { 0x09, 0x, 0x0080 },
>> -{ 0x19, 0x, 0x0224 }
>> +{ 0x19, 0x, 0x0224 },
>> +{ 0x00, 0x, 0x0008 },
>> +{ 0x0c, 0x3df0, 0x0200 }
> 
> I can't help feeling these lines all require short comments.

Agreed.

And this goes for some of the other patches that look like this too.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] drm/rockchip: fix dma_alloc_attrs() error check

[Daniel Kurtz]

On Wed, Jan 7, 2015 at 5:27 PM, Daniel Kurtz  wrote:
> dma_alloc_attrs() returns NULL if it cannot allocate a dma buffer (or
> mapping), not a negative error code.
>
> Rerported-by: Pawel Osciak 

Oops!  I just noticed that this is spelled wrong.  Should be "Reported-by".

Mark, could you fix up on your tree, or is it too late?

> Signed-off-by: Daniel Kurtz 
> ---
>  drivers/gpu/drm/rockchip/rockchip_drm_gem.c | 9 +++--
>  1 file changed, 3 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c 
> b/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
> index bc98a22..7ca8799e 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
> @@ -34,12 +34,9 @@ static int rockchip_gem_alloc_buf(struct 
> rockchip_gem_object *rk_obj)
> rk_obj->kvaddr = dma_alloc_attrs(drm->dev, obj->size,
>  _obj->dma_addr, GFP_KERNEL,
>  _obj->dma_attrs);
> -   if (IS_ERR(rk_obj->kvaddr)) {
> -   int ret = PTR_ERR(rk_obj->kvaddr);
> -
> -   DRM_ERROR("failed to allocate %#x byte dma buffer, %d",
> - obj->size, ret);
> -   return ret;
> +   if (!rk_obj->kvaddr) {
> +   DRM_ERROR("failed to allocate %#x byte dma buffer", 
> obj->size);
> +   return -ENOMEM;
> }
>
> return 0;
> --
> 2.2.0.rc0.207.ga3a616c
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [LKP] [mm] c8c06efa8b5: -7.6% unixbench.score

[Davidlohr Bueso]

On Fri, 2015-01-09 at 11:03 +0800, Huang Ying wrote:
> Is it possible for you to try the reproduce steps in the original
> reporting email sent by me?  If you have any question on that steps,
> feel free to ask.

Yes I've already done that, nothing. My question remains, can you
reproduce this yourself again? Thanks.

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

[PATCH 6/6] drivers:misc:ti-st: protect against bad packets

[Gigi Joseph]

We encounter situations where we got bad packet type from the
UART (probably due to platform problem or UART driver issues)
which caused us out of boundary array access,
which eventually led to kernel panic.

Signed-off-by: Amir Ayun 
Signed-off-by: Pavan Savoy 
Signed-off-by: Leonid Iziumtsev 
Signed-off-by: Gigi Joseph 
---
 drivers/misc/ti-st/st_core.c | 24 ++--
 1 file changed, 18 insertions(+), 6 deletions(-)

diff --git a/drivers/misc/ti-st/st_core.c b/drivers/misc/ti-st/st_core.c
index 54be83d..c8c6a36 100644
--- a/drivers/misc/ti-st/st_core.c
+++ b/drivers/misc/ti-st/st_core.c
@@ -343,12 +343,26 @@ void st_int_recv(void *disc_data,
/* Unknow packet? */
default:
type = *ptr;
-   if (st_gdata->list[type] == NULL) {
-   pr_err("chip/interface misbehavior dropping"
-   " frame starting with 0x%02x", type);
-   goto done;
 
+   /* Default case means non-HCILL packets,
+* possibilities are packets for:
+* (a) valid protocol -  Supported Protocols within
+* the ST_MAX_CHANNELS.
+* (b) registered protocol - Checked by
+* "st_gdata->list[type] == NULL)" are supported
+* protocols only.
+*  Rules out any invalid protocol and
+*  unregistered protocols with channel ID < 16.
+*/
+
+   if ((type >= ST_MAX_CHANNELS) ||
+   (st_gdata->list[type] == NULL)) {
+   pr_err("chip/interface misbehavior: "
+   "dropping frame starting "
+   "with 0x%02x\n", type);
+   goto done;
}
+
st_gdata->rx_skb = alloc_skb(
st_gdata->list[type]->max_frame_size,
GFP_ATOMIC);
@@ -893,5 +907,3 @@ void st_core_exit(struct st_data_s *st_gdata)
kfree(st_gdata);
}
 }
-
-
-- 
1.9.1

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

[PATCH 5/6] drivers: misc: ti-st: fix null pointer exception in st_kim_ref()

[Gigi Joseph]

st_kim_ref() does not take care of the fact that platform_get_drvdata() might 
return NULL. On AM437x EVM, this causes the platform to stop booting as soon as 
the module is inserted.

This patch fixes the issue by checking for NULL return value. Oops log follows.

I have not tested BT functionality after this patch. But at least the platform 
boots now.

[   12.675697] Unable to handle kernel NULL pointer dereference at virtual 
address 005c
[   12.684310] pgd = c0004000
[   12.687157] [005c] *pgd=
[   12.690927] Internal error: Oops: 17 [#1] SMP ARM
[   12.695873] Modules linked in: btwilink bluetooth ti_vpfe dwc3(+) ov2659 
videobuf2_core v4l2_common videodev ti_am335x_adc 6lowpan_iphc matrix_keypad 
panel_dpi kfifo_buf pixcir_i2c_ts media industrialio videobuf2_dma_contig 
c_can_platform videobuf2_memops dwc3_omap c_can can_dev
[   12.721969] CPU: 0 PID: 1235 Comm: kworker/u3:0 Not tainted 
3.14.25-02445-g9036ac6daed6 #128
[   12.730937] Workqueue: hci0 hci_power_on [bluetooth]
[   12.736165] task: ebd93b40 ti: ecd7c000 task.ti: ecd7c000
[   12.741856] PC is at st_kim_ref+0x30/0x40
[   12.746071] LR is at st_kim_ref+0x30/0x40
[   12.750289] pc : []lr : []psr: a013
[   12.750289] sp : ecd7de08  ip : ecd7de08  fp : ecd7de1c
[   12.762365] r10: bf1e710c  r9 : bf1e70ec  r8 : bf1e7964
[   12.767858] r7 : ebd2fd50  r6 : bf1e7964  r5 :   r4 : ecd7de24
[   12.774723] r3 : c0957208  r2 :   r1 : c0957208  r0 : 
[   12.781589] Flags: NzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment 
kernel
[   12.789274] Control: 10c5387d  Table: abde4059  DAC: 0015
[   12.795315] Process kworker/u3:0 (pid: 1235, stack limit = 0xecd7c248)

Signed-off-by: Sekhar Nori 
Signed-off-by: Gigi Joseph 
---
 drivers/misc/ti-st/st_kim.c | 12 
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/drivers/misc/ti-st/st_kim.c b/drivers/misc/ti-st/st_kim.c
index 878956a..7109d28 100644
--- a/drivers/misc/ti-st/st_kim.c
+++ b/drivers/misc/ti-st/st_kim.c
@@ -691,12 +691,16 @@ void st_kim_ref(struct st_data_s **core_data, int id)
struct kim_data_s   *kim_gdata;
/* get kim_gdata reference from platform device */
pdev = st_get_plat_device(id);
-   if (!pdev) {
-   *core_data = NULL;
-   return;
-   }
+   if (!pdev)
+   goto err;
kim_gdata = platform_get_drvdata(pdev);
+   if (!kim_gdata)
+   goto err;
+
*core_data = kim_gdata->core_data;
+   return;
+err:
+   *core_data = NULL;
 }
 
 static int kim_version_open(struct inode *i, struct file *f)
-- 
1.9.1

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

[PATCH 4/6] drivers: misc: ti-st: fix debugfs creation error handling

[Gigi Joseph]

In case the debugfs creation fails the whole init process was failing.
There is no need to do this as the shared transport can work without it.
Fix it so it just reports the failure and continue.

Signed-off-by: Eyal Reizer 
Signed-off-by: Gigi Joseph 
---
 drivers/misc/ti-st/st_kim.c | 6 +-
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/drivers/misc/ti-st/st_kim.c b/drivers/misc/ti-st/st_kim.c
index f2c1071..878956a 100644
--- a/drivers/misc/ti-st/st_kim.c
+++ b/drivers/misc/ti-st/st_kim.c
@@ -836,8 +836,7 @@ static int kim_probe(struct platform_device *pdev)
kim_debugfs_dir = debugfs_create_dir("ti-st", NULL);
if (!kim_debugfs_dir) {
pr_err(" debugfs entries creation failed ");
-   err = -EIO;
-   goto err_debugfs_dir;
+   return 0;
}
 
debugfs_create_file("version", S_IRUGO, kim_debugfs_dir,
@@ -846,9 +845,6 @@ static int kim_probe(struct platform_device *pdev)
kim_gdata, _debugfs_fops);
return 0;
 
-err_debugfs_dir:
-   sysfs_remove_group(>dev.kobj, _attr_grp);
-
 err_sysfs_group:
st_core_exit(kim_gdata->core_data);
 
-- 
1.9.1

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

[PATCH 3/6] btwilink: add minimal device tree support

[Gigi Joseph]

Add minimal device tree support to the btwilink driver that is used
for binding bluetooth with the ti-st shared transport driver.

Signed-off-by: Eyal Reizer 
Signed-off-by: bvijay 
Signed-off-by: Gigi Joseph 
---
 drivers/bluetooth/btwilink.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/drivers/bluetooth/btwilink.c b/drivers/bluetooth/btwilink.c
index 55c135b..95adec3 100644
--- a/drivers/bluetooth/btwilink.c
+++ b/drivers/bluetooth/btwilink.c
@@ -30,6 +30,7 @@
 
 #include 
 #include 
+#include 
 
 /* Bluetooth Driver Version */
 #define VERSION   "1.0"
@@ -286,6 +287,14 @@ static int ti_st_send_frame(struct hci_dev *hdev, struct 
sk_buff *skb)
return 0;
 }
 
+static const struct of_device_id btwilink_of_match[] = {
+{
+   .compatible = "btwilink",
+   },
+   {}
+};
+MODULE_DEVICE_TABLE(of, btwilink_of_match);
+
 static int bt_ti_probe(struct platform_device *pdev)
 {
static struct ti_st *hst;
@@ -349,6 +358,8 @@ static struct platform_driver btwilink_driver = {
.remove = bt_ti_remove,
.driver = {
.name = "btwilink",
+   .owner = THIS_MODULE,
+   .of_match_table = of_match_ptr(btwilink_of_match),
},
 };
 
-- 
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/6] st_kim: allow suspend if callback is not registered

[Gigi Joseph]

Suspend/resume was failing if callbacks were not registered.
As it is ok not to do anything when suspending fix this
so it soen't return an error and allow the system to suspend.

Signed-off-by: Eyal Reizer 
Signed-off-by: Gigi Joseph 
---
 drivers/misc/ti-st/st_kim.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/misc/ti-st/st_kim.c b/drivers/misc/ti-st/st_kim.c
index 68a0b58..f2c1071 100644
--- a/drivers/misc/ti-st/st_kim.c
+++ b/drivers/misc/ti-st/st_kim.c
@@ -908,7 +908,7 @@ static int kim_suspend(struct platform_device *pdev, 
pm_message_t state)
if (pdata->suspend)
return pdata->suspend(pdev, state);
 
-   return -EOPNOTSUPP;
+   return 0;
 }
 
 static int kim_resume(struct platform_device *pdev)
@@ -925,7 +925,7 @@ static int kim_resume(struct platform_device *pdev)
if (pdata->resume)
return pdata->resume(pdev);
 
-   return -EOPNOTSUPP;
+   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/

[PATCH 1/6] ti-st: add device tree support

[Gigi Joseph]

When using device tree, driver configuration data need to be read from
device node.
Add support for getting the platform data information from the device
tree information stored in the .dtb file in case it exists.

Signed-off-by: Eyal Reizer 
Signed-off-by: bvijay 
Diff rendering mode:inlineside by side

Signed-off-by: Gigi Joseph 
---
 drivers/misc/ti-st/st_kim.c  | 97 
 drivers/misc/ti-st/st_ll.c   | 17 +++-
 include/linux/ti_wilink_st.h |  1 +
 3 files changed, 105 insertions(+), 10 deletions(-)

diff --git a/drivers/misc/ti-st/st_kim.c b/drivers/misc/ti-st/st_kim.c
index e4b7ee4f..68a0b58 100644
--- a/drivers/misc/ti-st/st_kim.c
+++ b/drivers/misc/ti-st/st_kim.c
@@ -36,7 +36,8 @@
 #include 
 #include 
 #include 
-
+#include 
+#include 
 
 #define MAX_ST_DEVICES 3   /* Imagine 1 on each UART for now */
 static struct platform_device *st_kim_devices[MAX_ST_DEVICES];
@@ -44,6 +45,9 @@ static struct platform_device *st_kim_devices[MAX_ST_DEVICES];
 /**/
 /* internal functions */
 
+struct ti_st_plat_data *dt_pdata;
+static struct ti_st_plat_data *get_platform_data(struct device *dev);
+
 /**
  * st_get_plat_device -
  * function which returns the reference to the platform device
@@ -462,7 +466,12 @@ long st_kim_start(void *kim_data)
struct kim_data_s   *kim_gdata = (struct kim_data_s *)kim_data;
 
pr_info(" %s", __func__);
-   pdata = kim_gdata->kim_pdev->dev.platform_data;
+   if (kim_gdata->kim_pdev->dev.of_node) {
+   pr_debug("use device tree data");
+   pdata = dt_pdata;
+   } else {
+   pdata = kim_gdata->kim_pdev->dev.platform_data;
+   }
 
do {
/* platform specific enabling code here */
@@ -522,12 +531,18 @@ long st_kim_stop(void *kim_data)
 {
long err = 0;
struct kim_data_s   *kim_gdata = (struct kim_data_s *)kim_data;
-   struct ti_st_plat_data  *pdata =
-   kim_gdata->kim_pdev->dev.platform_data;
+   struct ti_st_plat_data  *pdata;
struct tty_struct   *tty = kim_gdata->core_data->tty;
 
reinit_completion(_gdata->ldisc_installed);
 
+   if (kim_gdata->kim_pdev->dev.of_node) {
+   pr_debug("use device tree data");
+   pdata = dt_pdata;
+   } else
+   pdata = kim_gdata->kim_pdev->dev.platform_data;
+
+
if (tty) {  /* can be called before ldisc is installed */
/* Flush any pending characters in the driver and discipline. */
tty_ldisc_flush(tty);
@@ -715,13 +730,53 @@ static const struct file_operations list_debugfs_fops = {
  * board-*.c file
  */
 
+static const struct of_device_id kim_of_match[] = {
+{
+   .compatible = "kim",
+   },
+   {}
+};
+MODULE_DEVICE_TABLE(of, kim_of_match);
+
+static struct ti_st_plat_data *get_platform_data(struct device *dev)
+{
+   struct device_node *np = dev->of_node;
+   const u32 *dt_property;
+   int len;
+
+   dt_pdata = kzalloc(sizeof(*dt_pdata), GFP_KERNEL);
+
+   if (!dt_pdata)
+   pr_err("Can't allocate device_tree platform data\n");
+
+   dt_property = of_get_property(np, "dev_name", );
+   if (dt_property)
+   memcpy(_pdata->dev_name, dt_property, len);
+   of_property_read_u32(np, "nshutdown_gpio",
+(u32 *)_pdata->nshutdown_gpio);
+   of_property_read_u32(np, "flow_cntrl", (u32 *)_pdata->flow_cntrl);
+   of_property_read_u32(np, "baud_rate", (u32 *)_pdata->baud_rate);
+
+   return dt_pdata;
+}
+
 static struct dentry *kim_debugfs_dir;
 static int kim_probe(struct platform_device *pdev)
 {
struct kim_data_s   *kim_gdata;
-   struct ti_st_plat_data  *pdata = pdev->dev.platform_data;
+   struct ti_st_plat_data  *pdata;
int err;
 
+   if (pdev->dev.of_node)
+   pdata = get_platform_data(>dev);
+   else
+   pdata = pdev->dev.platform_data;
+
+   if (pdata == NULL) {
+   dev_err(>dev, "Platform Data is missing\n");
+   return -ENXIO;
+   }
+
if ((pdev->id != -1) && (pdev->id < MAX_ST_DEVICES)) {
/* multiple devices could exist */
st_kim_devices[pdev->id] = pdev;
@@ -806,9 +861,16 @@ err_core_init:
 static int kim_remove(struct platform_device *pdev)
 {
/* free the GPIOs requested */
-   struct ti_st_plat_data  *pdata = pdev->dev.platform_data;
+   struct ti_st_plat_data  *pdata;
struct kim_data_s   *kim_gdata;
 
+   if (pdev->dev.of_node) {
+   pr_debug("use device tree data");
+   pdata = dt_pdata;
+   } else {
+   pdata = pdev->dev.platform_data;
+   }
+
kim_gdata = platform_get_drvdata(pdev);
 
/* Free the Bluetooth/FM/GPIO
@@ -826,12 +888,22 @@ static int 

Re: [PATCH 1/2] x86: Add Isolated Memory Regions for Quark X1000

[Darren Hart]

On Thu, Jan 08, 2015 at 03:11:35PM +, Bryan O'Donoghue wrote:
> 
> >Suggest to split the imr_del() into 2 functions:-
> >(1) by address + size
> >(2) by IMR index
> >At current implementation, it does not support (2) only because it fails at
> >imr_check_range().
> 
> Hi Boon Leong.
> 
> I'll have a think about that :)
> 
> Just on imr_del() though, it does support removal by way of index.
> 
> +static void __init intel_galileo_imr_init(void)
> +{
> + unsigned long base  = virt_to_phys(&_text);
> + unsigned long size = virt_to_phys(&_sinittext) - base - IMR_ALIGN;
> + int i, ret;
> +
> + /* Tear down all existing unlocked IMRs */
> + for (i = 0; i <= QUARK_X1000_IMR_NUM; i++)
> + imr_del(i, 0, 0);
> 
> That's what the platform code has to do for every unlocked IMR, to make sure
> there are no stale IMRs left that could conflict with the EFI memory map !

I'm OK with a single function so long as by index works without having to
specify the address. Please update the kernel doc to describe this usage though.

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

[PATCH v5][resend v5] of: replace Asahi Kasei Corp vendor prefix

[Kuninori Morimoto]

From: Kuninori Morimoto 

Current vendor-prefixes.txt already has "ak" prefix for Asahi Kasei Corp
by ae8c4209af2c(of: Add vendor prefix for Asahi Kasei Corp.)

It went through the appropriate review process. But, almost all
Asahi Kasei chip drivers are using "asahi-kasei" prefix today.
(arch/arm/boot/dts/tegra20-seaboard.dts only is using "ak,ak8975",
 but there are instances of "asahi-kasei,ak8975" in other dts files.
 And drivers/iio/magnetometer/ak8975.c doesn't support "ak,ak8975" prefix)
So, we made a mistake there.

In addition, checkpatch.pl reports WARNING if it is using "asahi-kasei"
prerfix in DT file.
(DT compatible string vendor "asahi-kasei" appears un-documented)

Marking it deprecated and warning with checkpatch is certainly
preferable. So, this patch replace "ak" to "asahi-kasei" in
vendor-prefixes.txt. (and fixup tegra20-seaboard)

OTOH, Asahi Kasei is usually referred to as "AKM", but this patch
doesn't care about it. Because no DT is using that today.

Signed-off-by: Kuninori Morimoto 
Acked-by: Thierry Reding 
Acked-by: Alexandre Courbot 
---
v4 -> v5

 - venter -> vendor on Subject
 - fixup Acked-by ordering

 .../devicetree/bindings/vendor-prefixes.txt|2 +-
 arch/arm/boot/dts/tegra20-seaboard.dts |2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt 
b/Documentation/devicetree/bindings/vendor-prefixes.txt
index 723999d..ddcb4cd 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -9,7 +9,6 @@ ad  Avionic Design GmbH
 adapteva   Adapteva, Inc.
 adiAnalog Devices, Inc.
 aeroflexgaislerAeroflex Gaisler AB
-ak Asahi Kasei Corp.
 allwinner  Allwinner Technology Co., Ltd.
 altr   Altera Corp.
 amcc   Applied Micro Circuits Corporation (APM, formally AMCC)
@@ -20,6 +19,7 @@ amstaos   AMS-Taos Inc.
 apmApplied Micro Circuits Corporation (APM)
 armARM Ltd.
 armadeus   ARMadeus Systems SARL
+asahi-kaseiAsahi Kasei Corp.
 atmel  Atmel Corporation
 auoAU Optronics Corporation
 avago  Avago Technologies
diff --git a/arch/arm/boot/dts/tegra20-seaboard.dts 
b/arch/arm/boot/dts/tegra20-seaboard.dts
index a1d4bf9..7f5cf80 100644
--- a/arch/arm/boot/dts/tegra20-seaboard.dts
+++ b/arch/arm/boot/dts/tegra20-seaboard.dts
@@ -405,7 +405,7 @@
clock-frequency = <40>;
 
magnetometer@c {
-   compatible = "ak,ak8975";
+   compatible = "asahi-kasei,ak8975";
reg = <0xc>;
interrupt-parent = <>;
interrupts = ;
-- 
1.7.9.5

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

[PATCH v1] regulator: pfuze100-regulator: add pfuze3000 support

[Robin Gong]

Add pfuze3000 chip support.

Signed-off-by: Robin Gong 
---
 .../devicetree/bindings/regulator/pfuze100.txt |  94 ++-
 drivers/regulator/pfuze100-regulator.c | 134 +++--
 include/linux/regulator/pfuze100.h |  14 +++
 3 files changed, 232 insertions(+), 10 deletions(-)

diff --git a/Documentation/devicetree/bindings/regulator/pfuze100.txt 
b/Documentation/devicetree/bindings/regulator/pfuze100.txt
index 34ef5d1..9b40db8 100644
--- a/Documentation/devicetree/bindings/regulator/pfuze100.txt
+++ b/Documentation/devicetree/bindings/regulator/pfuze100.txt
@@ -1,7 +1,7 @@
 PFUZE100 family of regulators
 
 Required properties:
-- compatible: "fsl,pfuze100" or "fsl,pfuze200"
+- compatible: "fsl,pfuze100", "fsl,pfuze200", "fsl,pfuze3000"
 - reg: I2C slave address
 
 Required child node:
@@ -14,6 +14,8 @@ Required child node:
   sw1ab,sw1c,sw2,sw3a,sw3b,sw4,swbst,vsnvs,vrefddr,vgen1~vgen6
   --PFUZE200
   sw1ab,sw2,sw3a,sw3b,swbst,vsnvs,vrefddr,vgen1~vgen6
+  --PFUZE3000
+  sw1a,sw1b,sw2,sw3,swbst,vsnvs,vrefddr,vldo1,vldo2,vccsd,v33,vldo3,vldo4
 
 Each regulator is defined using the standard binding for regulators.
 
@@ -205,3 +207,93 @@ Example 2: PFUZE200
};
};
};
+
+Example 3: PFUZE3000
+
+   pmic: pfuze3000@08 {
+   compatible = "fsl,pfuze3000";
+   reg = <0x08>;
+
+   regulators {
+   sw1a_reg: sw1a {
+   regulator-min-microvolt = <70>;
+   regulator-max-microvolt = <1475000>;
+   regulator-boot-on;
+   regulator-always-on;
+   regulator-ramp-delay = <6250>;
+   };
+   /* use sw1c_reg to align with pfuze100/pfuze200 */
+   sw1c_reg: sw1b {
+   regulator-min-microvolt = <70>;
+   regulator-max-microvolt = <1475000>;
+   regulator-boot-on;
+   regulator-always-on;
+   regulator-ramp-delay = <6250>;
+   };
+
+   sw2_reg: sw2 {
+   regulator-min-microvolt = <250>;
+   regulator-max-microvolt = <330>;
+   regulator-boot-on;
+   regulator-always-on;
+   };
+
+   sw3a_reg: sw3 {
+   regulator-min-microvolt = <90>;
+   regulator-max-microvolt = <165>;
+   regulator-boot-on;
+   regulator-always-on;
+   };
+
+   swbst_reg: swbst {
+   regulator-min-microvolt = <500>;
+   regulator-max-microvolt = <515>;
+   };
+
+   snvs_reg: vsnvs {
+   regulator-min-microvolt = <100>;
+   regulator-max-microvolt = <300>;
+   regulator-boot-on;
+   regulator-always-on;
+   };
+
+   vref_reg: vrefddr {
+   regulator-boot-on;
+   regulator-always-on;
+   };
+
+   vgen1_reg: vldo1 {
+   regulator-min-microvolt = <180>;
+   regulator-max-microvolt = <330>;
+   regulator-always-on;
+   };
+
+   vgen2_reg: vldo2 {
+   regulator-min-microvolt = <80>;
+   regulator-max-microvolt = <155>;
+   };
+
+   vgen3_reg: vccsd {
+   regulator-min-microvolt = <285>;
+   regulator-max-microvolt = <330>;
+   regulator-always-on;
+   };
+
+   vgen4_reg: v33 {
+   regulator-min-microvolt = <285>;
+   regulator-max-microvolt = <330>;
+   };
+
+   vgen5_reg: vldo3 {
+   regulator-min-microvolt = <180>;
+   regulator-max-microvolt = <330>;
+   regulator-always-on;
+   };
+
+   vgen6_reg: vldo4 {
+   regulator-min-microvolt = <180>;
+   regulator-max-microvolt = <330>;
+  

Re: [PATCH v5][resend v4] of: replace Asahi Kasei Corp vendor prefix

[Kuninori Morimoto]

Hi Stephen, Olof, Arnd, Rob, Andrew

I'm sending this "of: replace Asahi Kasei Corp vendor prefix" during
half-year (since Jun 2014) , many times. But, no-one care it.
I don't know who is the best maintainer.
 - Stephen : because it has Tegra ?
 - Olof: because it has Tegra (= ARM) ?
 - Arnd: because it has Tegra (= ARM) ?
 - Matthias: because it has Tegra (= ARM SoC) ?
 - Rob : because DT ?
 - Andrew  : Last chance ?

But, could you please care this patch ?
I will re-send it again

> From: Kuninori Morimoto 
> 
> Current vendor-prefixes.txt already has "ak" prefix for Asahi Kasei Corp
> by ae8c4209af2c(of: Add vendor prefix for Asahi Kasei Corp.)
> 
> It went through the appropriate review process. But, almost all
> Asahi Kasei chip drivers are using "asahi-kasei" prefix today.
> (arch/arm/boot/dts/tegra20-seaboard.dts only is using "ak,ak8975",
>  but there are instances of "asahi-kasei,ak8975" in other dts files.
>  And drivers/iio/magnetometer/ak8975.c doesn't support "ak,ak8975" prefix)
> So, we made a mistake there.
> 
> In addition, checkpatch.pl reports WARNING if it is using "asahi-kasei"
> prerfix in DT file.
> (DT compatible string vendor "asahi-kasei" appears un-documented)
> 
> Marking it deprecated and warning with checkpatch is certainly
> preferable. So, this patch replace "ak" to "asahi-kasei" in
> vendor-prefixes.txt. (and fixup tegra20-seaboard)
> 
> OTOH, Asahi Kasei is usually referred to as "AKM", but this patch
> doesn't care about it. Because no DT is using that today.
> 
> Signed-off-by: Kuninori Morimoto 
> Acked-by: Thierry Reding 
> Acked-by: Alexandre Courbot 
> ---
> >> Linus
> 
> I had sent this patch to Linux ML and Maintainers many times,
> but, no-one cares about it.
> Can you please check and apply it ?
> 
> 
>  .../devicetree/bindings/vendor-prefixes.txt|2 +-
>  arch/arm/boot/dts/tegra20-seaboard.dts |2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt 
> b/Documentation/devicetree/bindings/vendor-prefixes.txt
> index 723999d..ddcb4cd 100644
> --- a/Documentation/devicetree/bindings/vendor-prefixes.txt
> +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
> @@ -9,7 +9,6 @@ adAvionic Design GmbH
>  adapteva Adapteva, Inc.
>  adi  Analog Devices, Inc.
>  aeroflexgaisler  Aeroflex Gaisler AB
> -ak   Asahi Kasei Corp.
>  allwinnerAllwinner Technology Co., Ltd.
>  altr Altera Corp.
>  amcc Applied Micro Circuits Corporation (APM, formally AMCC)
> @@ -20,6 +19,7 @@ amstaos AMS-Taos Inc.
>  apm  Applied Micro Circuits Corporation (APM)
>  arm  ARM Ltd.
>  armadeus ARMadeus Systems SARL
> +asahi-kasei  Asahi Kasei Corp.
>  atmelAtmel Corporation
>  auo  AU Optronics Corporation
>  avagoAvago Technologies
> diff --git a/arch/arm/boot/dts/tegra20-seaboard.dts 
> b/arch/arm/boot/dts/tegra20-seaboard.dts
> index a1d4bf9..7f5cf80 100644
> --- a/arch/arm/boot/dts/tegra20-seaboard.dts
> +++ b/arch/arm/boot/dts/tegra20-seaboard.dts
> @@ -405,7 +405,7 @@
>   clock-frequency = <40>;
>  
>   magnetometer@c {
> - compatible = "ak,ak8975";
> + compatible = "asahi-kasei,ak8975";
>   reg = <0xc>;
>   interrupt-parent = <>;
>   interrupts = ;
> -- 
> 1.7.9.5
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 1/2] Add another clock for use with the soft lockup watchdog.

[Cyril Bur]

This permits the use of arch specific clocks for which virtualised kernels can
use their notion of 'running' time, not the elpased wall time which will
include host execution time.

Signed-off-by: Cyril Bur 
---
V2:
   Remove the export of running_clock
   Use local_clock instead of sched_clock as was initally used in the
softlockup detector

---
 include/linux/sched.h |  1 +
 kernel/sched/clock.c  | 13 +
 kernel/watchdog.c |  2 +-
 3 files changed, 15 insertions(+), 1 deletion(-)

diff --git a/include/linux/sched.h b/include/linux/sched.h
index 8db31ef..e400162 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -2145,6 +2145,7 @@ extern unsigned long long notrace sched_clock(void);
  */
 extern u64 cpu_clock(int cpu);
 extern u64 local_clock(void);
+extern u64 running_clock(void);
 extern u64 sched_clock_cpu(int cpu);
 
 
diff --git a/kernel/sched/clock.c b/kernel/sched/clock.c
index c27e4f8..c0a2051 100644
--- a/kernel/sched/clock.c
+++ b/kernel/sched/clock.c
@@ -420,3 +420,16 @@ u64 local_clock(void)
 
 EXPORT_SYMBOL_GPL(cpu_clock);
 EXPORT_SYMBOL_GPL(local_clock);
+
+/*
+ * Running clock - returns the time that has elapsed while a guest has been
+ * running.
+ * On a guest this value should be local_clock minus the time the guest was
+ * suspended by the hypervisor (for any reason).
+ * On bare metal this function should return the same as local_clock.
+ * Architectures and sub-architectures can override this.
+ */
+u64 __weak running_clock(void)
+{
+   return local_clock();
+}
diff --git a/kernel/watchdog.c b/kernel/watchdog.c
index 70bf118..3174bf8 100644
--- a/kernel/watchdog.c
+++ b/kernel/watchdog.c
@@ -154,7 +154,7 @@ static int get_softlockup_thresh(void)
  */
 static unsigned long get_timestamp(void)
 {
-   return local_clock() >> 30LL;  /* 2^30 ~= 10^9 */
+   return running_clock() >> 30LL;  /* 2^30 ~= 10^9 */
 }
 
 static void set_sample_period(void)
-- 
1.9.1

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

[PATCH v2 2/2] powerpc: add running_clock for powerpc to prevent spurious softlockup warnings

[Cyril Bur]

On POWER8 virtualised kernels the VTB register can be read to have a view of
time that only increases while the guest is running. This will prevent guests
from seeing time jump if a guest is paused for significant amounts of time.

On POWER7 and below virtualised kernels stolen time is subtracted from
local_clock as a best effort approximation. This will not eliminate spurious
warnings in the case of a suspended guest but may reduce the occurance in the
case of softlockups due to host over commit.

Bare metal kernels should avoid reading the VTB as KVM does not restore sane
values when not executing, the approxmation is fine as host kernels won't
observe any stolen time.

Signed-off-by: Cyril Bur 
---
V2:
   Replaced the use of sched_clock_with local_clock it was used originally in
the softlockup detector.
   Added #ifdef CONFIG_PPC_PSERIES and optimised the non lpar + vtb cases.

---
 arch/powerpc/kernel/time.c | 32 
 1 file changed, 32 insertions(+)

diff --git a/arch/powerpc/kernel/time.c b/arch/powerpc/kernel/time.c
index fa7c4f1..fd35e5b 100644
--- a/arch/powerpc/kernel/time.c
+++ b/arch/powerpc/kernel/time.c
@@ -621,6 +621,38 @@ unsigned long long sched_clock(void)
return mulhdu(get_tb() - boot_tb, tb_to_ns_scale) << tb_to_ns_shift;
 }
 
+
+#ifdef CONFIG_PPC_PSERIES
+
+/*
+ * Running clock - attempts to give a view of time passing for a virtualised
+ * kernels.
+ * Uses the VTB register if available otherwise a next best guess.
+ */
+unsigned long long running_clock(void)
+{
+   /*
+* Don't read the VTB as a host since KVM does not switch in host 
timebase
+* into the VTB when it takes a guest off the CPU, reading the VTB would
+* result in reading 'last switched out' guest VTB.
+*
+* Host kernels are often compiled with CONFIG_PSERIES checked, it 
would be
+* unsafe to rely only on the #ifdef above.
+*/
+   if (firmware_has_feature(FW_FEATURE_LPAR) &&
+   cpu_has_feature(CPU_FTR_ARCH_207S))
+   return mulhdu(get_vtb() - boot_tb, tb_to_ns_scale) << 
tb_to_ns_shift;
+
+   /*
+* This is a next best approximation without a VTB.
+* On a host which is running bare metal there should never be any 
stolen
+* time and on a host which doesn't do any virtualisation TB *should* 
equal
+* VTB so it makes no difference anyway.
+*/
+   return local_clock() - 
cputime_to_nsecs(kcpustat_this_cpu->cpustat[CPUTIME_STEAL]);
+}
+#endif
+
 static int __init get_freq(char *name, int cells, unsigned long *val)
 {
struct device_node *cpu;
-- 
1.9.1

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

[PATCH v2 0/2] Quieten softlockup detector on virtualised kernels

[Cyril Bur]

When the hypervisor pauses a virtualised kernel the kernel will observe a jump
in timebase, this can cause spurious messages from the softlockup detector.

Whilst these messages are harmless, they are accompanied with a stack trace
which causes undue concern and more problematically the stack trace in the
guest has nothing to do with the observed problem and can only be misleading.

Futhermore, on POWER8 this is completely avoidable with the introduction of
the Virtual Time Base (VTB) register.

V2:
Remove the export of running_clock
Added #ifdef CONFIG_PPC_PSERIES and optimised the non lpar + vtb cases.
Replaced the use of sched_clock_with local_clock it was used originally 
in
the softlockup detector.

Cyril Bur (2):
  Add another clock for use with the soft lockup watchdog.
  powerpc: add running_clock for powerpc to prevent spurious softlockup
warnings

 arch/powerpc/kernel/time.c | 32 
 include/linux/sched.h  |  1 +
 kernel/sched/clock.c   | 13 +
 kernel/watchdog.c  |  2 +-
 4 files changed, 47 insertions(+), 1 deletion(-)

-- 
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 1/2] mm/slub: optimize alloc/free fastpath by removing preemption on/off

[Christoph Lameter]

On Thu, 8 Jan 2015, Joonsoo Kim wrote:

> > You'd need a smp_wmb() in between tid and c in the loop then, which
> > looks quite unpleasant. All in all disabling preemption isn't really
> > that expensive, and you should redo your performance number if you go
> > this way.
>
> This barrier() is not for read/write synchronization between cpus.
> All read/write operation to cpu_slab would happen on correct cpu in
> successful case. What I'd need to guarantee here is to prevent
> reordering between fetching operation for correctness of algorithm. In
> this case, barrier() seems enough to me. Am I wrong?

You are right.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v8 1/2] crypto: AF_ALG: add AEAD support

[Stephan Mueller]

Am Donnerstag, 8. Januar 2015, 22:09:31 schrieb Herbert Xu:

Hi Herbert,

> On Wed, Jan 07, 2015 at 04:51:38PM +0100, Stephan Mueller wrote:
> > +   if (!aead_writable(sk)) {
> > +   /*
> > +* If there is more data to be expected, but we cannot
> > +* write more data, forcefully define that we do not
> > +* expect more data to invoke the AEAD operation. This
> > +* prevents a deadlock in user space.
> > +*/
> > +   ctx->more = 0;
> 
> We should return EMSGSIZE here.  Also we should clear out the
> existing data so that the socket may be reused again.

Is this really wise considering that we want to support a threaded caller? For 
example, one thread sends data and another reads data. For some reason, the 
reading thread is throttled or slower than the sender. Now, with the current 
solution, the sender is put on hold (i.e. throttled) until the reader can 
catch up. I.e. we have an automated synchronization between sender/receiver.

Thus, when we remove the wait here and return an error, the sender will be 
shut down and there is no synchronization of the reader/writer any more.

Note, the same applies to the very similar code in aead_sendpage too.
> 
> > +   ctx->more = msg->msg_flags & MSG_MORE;
> > +   if (!ctx->more && !aead_sufficient_data(ctx))
> > +   err = -EINVAL;
> 
> Ditto, we should discard the data that's queued up.  Also perhaps
> use EBADMSG instead of EINVAL.

Agreed that we should clear out the buffer. I will provide that in the next 
release for both, the sendmsg and sendpage implementations.

However, I am not sure whether using EBADMSG is a good idea. The error of 
EBADMSG in the kernel crypto API is only used for integrity errors of AEAD 
ciphers. But our error case here has nothing to do with the integrity error.

I would be fine with any other error number -- EMSGSIZE as you suggested 
above?
> 
> > +   /*
> > +* Require exactly one IOV block as the AEAD operation is a one shot
> > +* due to the authentication tag.
> > +*/
> > +   if (msg->msg_iter.nr_segs != 1)
> > +   return -ENOMSG;
> 
> Why does the receive buffer have to be contiguous?

I thought for quite some time about how we can use multiple iovecs. But I 
found no satisfactory solution. The solution I see is described below.

If we consider the skcipher implementation, the code iterates over the iovecs 
as the outermost loop. In each loop iteration the cipher operation is 
triggered.

Now in case of AEAD, all provided data the kernel received has to be operated 
on with exactly one cipher invocation. Looking at skcipher, that would mean 
that we only perform one loop iteration, i.e. processing exactly one iovec.

A possible solution would be that I use an array of struct af_alg_sgl and 
iterate over that array for each iovec. Something like the following:

struct aead_ctx {
...
struct af_alg_sgl rsgl[ALG_MAX_PAGES];

for(i = 0; i < ALG_MAX_PAGES; i++) {
af_alg_make_sg(rsgl[i], iov[i])
scatterwalk_sg_chain(rsgl[i-1].sg rsgl[i]);
}

But my concern is that with the array of rsgl we occupy a sizable amount of 
memory as af_alg_sgl again defines arrays of entries.

Do you think whether such approach makes sense? If yes, which limit to the 
number of rsgl should we apply -- is ALG_MAX_PAGES good?

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

[PATCHv6 4/5] edac: altera: Add Altera L2 Cache and OCRAM EDAC Support

[tthayer]

From: Thor Thayer 

Adding L2 Cache and On-Chip RAM EDAC support for the
Altera SoCs using the EDAC device  model. The SDRAM
controller is using the Memory Controller model.

Each type of ECC is individually configurable.

The SDRAM ECC is a separate Kconfig option because:
1) the SDRAM preparation can take almost 2 seconds on boot and some
customers need a faster boot time.
2) the SDRAM has an ECC initialization dependency on the preloader
which is outside the kernel. It is desirable to be able to turn the
SDRAM on & off separately.

Signed-off-by: Thor Thayer 
---
v2: Fix L2 dependency comments.

v3: Move OCRAM and L2 cache EDAC functions into altera_edac.c
instead of separate files.

v4: Change mask defines to use BIT().
Fix comment style to agree with kernel coding style.
Better printk description for read != write in trigger.
Remove SysFS debugging message.
Better dci->mod_name
Move gen_pool pointer assignment to end of function.
Invert logic to reduce indent in ocram depenency check.
Change from dev_err() to edac_printk()
Replace magic numbers with defines & comments.
Improve error injection test.
Change Makefile intermediary name to altr (from alt)

v5: No change.

v6: Convert to nested EDAC in device tree. Force L2 cache
on for L2Cache ECC & remove L2 cache syscon for checking
enable bit. Update year in header.
---
 drivers/edac/Kconfig   |   16 ++
 drivers/edac/Makefile  |5 +-
 drivers/edac/altera_edac.c |  506 +++-
 3 files changed, 524 insertions(+), 3 deletions(-)

diff --git a/drivers/edac/Kconfig b/drivers/edac/Kconfig
index 4d7285e..edf97ed 100644
--- a/drivers/edac/Kconfig
+++ b/drivers/edac/Kconfig
@@ -385,4 +385,20 @@ config EDAC_ALTERA_MC
  preloader must initialize the SDRAM before loading
  the kernel.
 
+config EDAC_ALTERA_L2C
+   bool "Altera L2 Cache EDAC"
+   depends on EDAC_MM_EDAC=y && ARCH_SOCFPGA
+   select CACHE_L2X0
+   help
+ Support for error detection and correction on the
+ Altera L2 cache Memory for Altera SoCs. This option
+  requires L2 cache so it will force that selection.
+
+config EDAC_ALTERA_OCRAM
+   bool "Altera On-Chip RAM EDAC"
+   depends on EDAC_MM_EDAC=y && ARCH_SOCFPGA && SRAM && GENERIC_ALLOCATOR
+   help
+ Support for error detection and correction on the
+ Altera On-Chip RAM Memory for Altera SoCs.
+
 endif # EDAC
diff --git a/drivers/edac/Makefile b/drivers/edac/Makefile
index d40c69a..b9a67c0 100644
--- a/drivers/edac/Makefile
+++ b/drivers/edac/Makefile
@@ -66,4 +66,7 @@ obj-$(CONFIG_EDAC_OCTEON_L2C) += octeon_edac-l2c.o
 obj-$(CONFIG_EDAC_OCTEON_LMC)  += octeon_edac-lmc.o
 obj-$(CONFIG_EDAC_OCTEON_PCI)  += octeon_edac-pci.o
 
-obj-$(CONFIG_EDAC_ALTERA_MC)   += altera_edac.o
+altr_edac-y:= altera_edac.o
+obj-$(CONFIG_EDAC_ALTERA_MC)   += altr_edac.o
+obj-$(CONFIG_EDAC_ALTERA_L2C)  += altr_edac.o
+obj-$(CONFIG_EDAC_ALTERA_OCRAM)+= altr_edac.o
diff --git a/drivers/edac/altera_edac.c b/drivers/edac/altera_edac.c
index 3c4929f..083cd20 100644
--- a/drivers/edac/altera_edac.c
+++ b/drivers/edac/altera_edac.c
@@ -1,5 +1,5 @@
 /*
- *  Copyright Altera Corporation (C) 2014. All rights reserved.
+ *  Copyright Altera Corporation (C) 2014-2015. All rights reserved.
  *  Copyright 2011-2012 Calxeda, Inc.
  *
  * This program is free software; you can redistribute it and/or modify it
@@ -17,8 +17,10 @@
  * Adapted from the highbank_mc_edac driver.
  */
 
+#include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -33,6 +35,7 @@
 
 #define EDAC_MOD_STR   "altera_edac"
 #define EDAC_VERSION   "1"
+#define EDAC_DEVICE"ALTR_MEM"
 
 /* SDRAM Controller CtrlCfg Register */
 #define CTLCFG_OFST 0x00
@@ -107,6 +110,33 @@ struct altr_sdram_mc_data {
struct regmap *mc_vbase;
 };
 
+/** EDAC Device Defines **/
+
+/* OCRAM ECC Management Group Defines */
+#define ALTR_MAN_GRP_OCRAM_ECC_OFFSET   0x04
+#define ALTR_OCR_ECC_EN_MASKBIT(0)
+#define ALTR_OCR_ECC_INJS_MASK  BIT(1)
+#define ALTR_OCR_ECC_INJD_MASK  BIT(2)
+#define ALTR_OCR_ECC_SERR_MASK  BIT(3)
+#define ALTR_OCR_ECC_DERR_MASK  BIT(4)
+
+/* L2 ECC Management Group Defines */
+#define ALTR_MAN_GRP_L2_ECC_OFFSET  0x00
+#define ALTR_L2_ECC_EN_MASK BIT(0)
+#define ALTR_L2_ECC_INJS_MASK   BIT(1)
+#define ALTR_L2_ECC_INJD_MASK   BIT(2)
+
+#define ALTR_UE_TRIGGER_CHAR'U'   /* Trigger for UE */
+#define ALTR_TRIGGER_READ_WRD_CNT   32/* Line size x 4 */
+#define ALTR_TRIG_OCRAM_BYTE_SIZE   128   /* Line size x 4 */
+#define ALTR_TRIG_L2C_BYTE_SIZE 4096  /* Full Page */
+
+/*** EDAC Memory Controller Functions 

[PATCHv6 3/5] edac: altera: Remove SDRAM module compile

[tthayer]

From: Thor Thayer 

The SDRAM EDAC requires SDRAM configuration/initialization before
SDRAM is accessed (in the preloader). Having a module compile is
not desired so force to be built into kernel.

Signed-off-by: Thor Thayer 
---
v3: Added in this version as a separate patch.

v4-6: No change.
---
 drivers/edac/Kconfig |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/edac/Kconfig b/drivers/edac/Kconfig
index 49c2652..4d7285e 100644
--- a/drivers/edac/Kconfig
+++ b/drivers/edac/Kconfig
@@ -377,8 +377,8 @@ config EDAC_OCTEON_PCI
  Cavium Octeon family of SOCs.
 
 config EDAC_ALTERA_MC
-   tristate "Altera SDRAM Memory Controller EDAC"
-   depends on EDAC_MM_EDAC && ARCH_SOCFPGA
+   bool "Altera SDRAM Memory Controller EDAC"
+   depends on EDAC_MM_EDAC=y && ARCH_SOCFPGA
help
  Support for error detection and correction on the
  Altera SDRAM memory controller. Note that the
-- 
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/

[PATCHv6 2/5] arm: socfpga: Enable OCRAM ECC on startup.

[tthayer]

From: Thor Thayer 

This patch enables the ECC for On-Chip RAM on machine
startup.  The ECC has to be enabled before data is
is stored in memory otherwise the ECC will fail on
reads.

Signed-off-by: Thor Thayer 
---
v2: Split OCRAM ECC portion separately. Addition of iounmap()
and reorganization of gen_pool_free. Remove defconfig from patch.

v3/4: No change

v5: Remove ocram.h, use io.h instead of clk-provider.h
Check prop in correct place. Add ECC EN defines.

v6: Implement OCRAM discovery changes from community. Add
of_node_put(). Remove be32_to_cpup(). Use __init() which
allows removal of .init_machine(). Update year in header.
---
 arch/arm/mach-socfpga/Makefile |1 +
 arch/arm/mach-socfpga/ocram.c  |   97 
 2 files changed, 98 insertions(+)
 create mode 100644 arch/arm/mach-socfpga/ocram.c

diff --git a/arch/arm/mach-socfpga/Makefile b/arch/arm/mach-socfpga/Makefile
index 142609e..1552ca5 100644
--- a/arch/arm/mach-socfpga/Makefile
+++ b/arch/arm/mach-socfpga/Makefile
@@ -5,3 +5,4 @@
 obj-y  := socfpga.o
 obj-$(CONFIG_SMP)  += headsmp.o platsmp.o
 obj-$(CONFIG_EDAC_ALTERA_L2C) += l2_cache.o
+obj-$(CONFIG_EDAC_ALTERA_OCRAM) += ocram.o
diff --git a/arch/arm/mach-socfpga/ocram.c b/arch/arm/mach-socfpga/ocram.c
new file mode 100644
index 000..1f12a38
--- /dev/null
+++ b/arch/arm/mach-socfpga/ocram.c
@@ -0,0 +1,97 @@
+/*
+ * Copyright Altera Corporation (C) 2015. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program.  If not, see .
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define ALTR_OCRAM_CLEAR_ECC  0x0018
+#define ALTR_OCRAM_ECC_EN 0x0019
+
+static int __init socfpga_init_ocram_ecc(void)
+{
+   struct device_node *np;
+   struct resourceres;
+   u32iram_addr;
+   void __iomem   *mapped_ocr_edac_addr;
+   resource_size_tsize;
+   struct gen_pool*gp;
+   intret;
+
+   /* Get the size of the on-chip RAM */
+   np = of_find_compatible_node(NULL, NULL, "mmio-sram");
+   if (!np) {
+   pr_err("%s: Unable to find mmio-sram in dtb\n", __func__);
+   return -ENODEV;
+   }
+
+   ret = of_address_to_resource(np, 0, );
+   if (ret) {
+   of_node_put(np);
+   pr_err("%s: Problem getting SRAM address in dtb\n", __func__);
+   return -ENODEV;
+   }
+   size = resource_size();
+   of_node_put(np);
+
+   /* Find the OCRAM EDAC device tree node */
+   np = of_find_compatible_node(NULL, NULL, "altr,ocram-edac");
+   if (!np) {
+   pr_err("%s: Unable to find altr,ocram-edac\n", __func__);
+   return -ENODEV;
+   }
+
+   mapped_ocr_edac_addr = of_iomap(np, 0);
+   if (!mapped_ocr_edac_addr) {
+   of_node_put(np);
+   pr_err("%s: Unable to map OCRAM ecc regs.\n", __func__);
+   return -ENODEV;
+   }
+
+   gp = of_get_named_gen_pool(np, "iram", 0);
+   if (!gp) {
+   of_node_put(np);
+   pr_err("%s: OCRAM cannot find gen pool\n", __func__);
+   return -ENODEV;
+   }
+   of_node_put(np);
+
+   iram_addr = gen_pool_alloc(gp, size / sizeof(size_t));
+   if (iram_addr == 0) {
+   pr_err("%s: cannot alloc from gen pool\n", __func__);
+   return -ENODEV;
+   }
+
+   /* Clear any pending OCRAM ECC interrupts, then enable ECC */
+   writel(ALTR_OCRAM_CLEAR_ECC, mapped_ocr_edac_addr);
+   writel(ALTR_OCRAM_ECC_EN, mapped_ocr_edac_addr);
+
+   memset((void *)iram_addr, 0, size);
+
+   gen_pool_free(gp, iram_addr, size / sizeof(size_t));
+
+   iounmap(mapped_ocr_edac_addr);
+
+   return 0;
+}
+
+static void __exit socfpga_exit_ocram_ecc(void)
+{
+}
+
+module_init(socfpga_init_ocram_ecc);
+module_exit(socfpga_exit_ocram_ecc);
-- 
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/

[PATCHv6 0/5] Add Altera peripheral memories to EDAC framework

[tthayer]

From: Thor Thayer 

This patch adds the L2 cache and OCRAM peripherals to the EDAC framework
using the EDAC device framework. The ECC is enabled early in the boot
process in the platform specific code.

v2 changes:
- Split On-Chip RAM ECC platform initialization into separate patch from
  L2 ECC platform initialization.
- Fix L2 cache dependency comments.
- Remove OCRAM node from dts and reference prior patch.

v3 changes:
- Move L2 cache & On-Chip RAM EDAC code into altera_edac.c
- Remove SDRAM module compile.

v4 changes:
- Change mask defines to use BIT().
- Fix comment style to agree with kernel coding style.
- Better printk description for read != write in trigger.
- Remove SysFS debugging message.
- Better dci->mod_name
- Move gen_pool pointer assignment to end of function.
- Invert logic to reduce indent in ocram depenency check.
- Change from dev_err() to edac_printk()
- Replace magic numbers with defines & comments.
- Improve error injection test.
- Change Makefile intermediary name to altr (from alt)

v5 changes:
- Remove l2cache.h by using if (IS_ENABLED(CONFIG_EDAC_ALTERA_L2C))
- Remove ocram.h by using if (IS_ENABLED(CONFIG_EDAC_ALTERA_OCRAM))
- Check prop variable before using. Include io.h.
- Add defines for better readability. Remove MAINTAINERS changes.

v6 changes:
- Simplify OCRAM initialization. Remove be32_to_cpup() calls.
- Remove syscon from L2 Cache. Force L2 Cache on if ECC enabled.
- Convert to nested ECC in device tree. 
- Additional comments to clarify debug error injection.

Thor Thayer (5):
  arm: socfpga: Enable L2 Cache ECC on startup.
  arm: socfpga: Enable OCRAM ECC on startup.
  edac: altera: Remove SDRAM module compile
  edac: altera: Add Altera L2 Cache and OCRAM EDAC Support
  arm: dts: Add Altera L2 Cache and OCRAM EDAC entries

 .../bindings/arm/altera/socfpga-edac.txt   |   46 ++
 arch/arm/boot/dts/socfpga.dtsi |   20 +
 arch/arm/mach-socfpga/Makefile |2 +
 arch/arm/mach-socfpga/core.h   |2 +
 arch/arm/mach-socfpga/l2_cache.c   |   39 ++
 arch/arm/mach-socfpga/ocram.c  |   97 
 arch/arm/mach-socfpga/socfpga.c|4 +-
 drivers/edac/Kconfig   |   20 +-
 drivers/edac/Makefile  |5 +-
 drivers/edac/altera_edac.c |  506 +++-
 10 files changed, 735 insertions(+), 6 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/arm/altera/socfpga-edac.txt
 create mode 100644 arch/arm/mach-socfpga/l2_cache.c
 create mode 100644 arch/arm/mach-socfpga/ocram.c

-- 
1.7.9.5

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

Re: [PATCH 2/2] powerpc: add running_clock for powerpc to prevent spurious softlockup warnings

[Cyril Bur]

On Wed, 2015-01-07 at 11:20 +0100, Martin Schwidefsky wrote:
> On Tue, 06 Jan 2015 13:44:01 +1100
> Cyril Bur  wrote:
> 
> > On Mon, 2015-01-05 at 14:10 -0800, Andrew Morton wrote:
> > > On Mon, 22 Dec 2014 16:06:04 +1100 Cyril Bur  wrote:
> > > 
> > > > On POWER8 virtualised kernels the VTB register can be read to have a 
> > > > view of
> > > > time that only increases while the guest is running. This will prevent 
> > > > guests
> > > > from seeing time jump if a guest is paused for significant amounts of 
> > > > time.
> > > > 
> > > > On POWER7 and below virtualised kernels stolen time is subtracted from
> > > > sched_clock as a best effort approximation. This will not eliminate 
> > > > spurious
> > > > warnings in the case of a suspended guest but may reduce the occurance 
> > > > in the
> > > > case of softlockups due to host over commit.
> > > > 
> > > > Bare metal kernels should avoid reading the VTB as KVM does not restore 
> > > > sane
> > > > values when not executing. sched_clock is returned in this case.
> > > > 
> > > > --- a/arch/powerpc/kernel/time.c
> > > > +++ b/arch/powerpc/kernel/time.c
> > > > @@ -621,6 +621,30 @@ unsigned long long sched_clock(void)
> > > > return mulhdu(get_tb() - boot_tb, tb_to_ns_scale) << 
> > > > tb_to_ns_shift;
> > > >  }
> > > >  
> > > > +unsigned long long running_clock(void)
> > > 
> > > Non-kvm kernels don't need this code.  Is there some appropriate
> > > "#ifdef CONFIG_foo" we can wrap this in?
> > CONFIG_PSERIES would work, having said that typical compilation for a
> > powernv kernel almost always includes CONFIG_PSERIES (although it
> > doesn't need to)... still, your point is valid, will add in v2.
> > > 
> > > 
> > > > +{
> > > > +   /*
> > > > +* Don't read the VTB as a host since KVM does not switch in 
> > > > host timebase
> > > > +* into the VTB when it takes a guest off the CPU, reading the 
> > > > VTB would
> > > > +* result in reading 'last switched out' guest VTB.
> > > > +*/
> > > > +
> > > > +   if (firmware_has_feature(FW_FEATURE_LPAR)) {
> > > > +   if (cpu_has_feature(CPU_FTR_ARCH_207S))
> > > > +   return mulhdu(get_vtb() - boot_tb, 
> > > > tb_to_ns_scale) << tb_to_ns_shift;
> > > > +
> > > > +   /* This is a next best approximation without a VTB. */
> > > > +   return sched_clock() - 
> > > > cputime_to_nsecs(kcpustat_this_cpu->cpustat[CPUTIME_STEAL]);
> > > 
> > > Why is this result dependent on FW_FEATURE_LPAR?  It's all generic code.
> > Good point, the reason it ended up there is because I wanted to avoid
> > behaviour changes.
> > > 
> > > In fact the kernel/sched/clock.c default implementation of
> > > running_clock() could use this expression.  Would that be good or bad? :)
> > For power I'm almost certain it would be fine, on platforms which don't
> > do stolen time cpustat[CPUTIME_STEAL] should always be zero and if not
> > then the value should always be sane (although as mentioned in the
> > comment, not as accurate as using the VTB).
> > 
> > Putting it in the default implementation could cause behavioural changes
> > for x86 and s390, I would want their views on doing that.
> 
> I would prefer to make sched_clock do all the work. We have been thinking
> about steal time vs sched_clock as well, our solution would be to exchange
> the time source. Right now sched_clock is based on the TOD clock, the code
> that takes steal time into account would use the CPU timer instead.
> With the subtraction of kcpustat_this_cpu->cpustat[CPUTIME_STEAL] in
> common code we would have to add the same value in the sched_clock
> implementation as the steal time is already included in the CPU timer
> deltas.

Thanks for the quick reply Martin,
Sound like you've got ideas and while I didn't really grasp all of that,
I gather we best leave the common code as is.
> 


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/2] Quieten softlockup detector on virtualised kernels

[Cyril Bur]

On Tue, 2015-01-06 at 10:01 -0500, Don Zickus wrote:
> On Tue, Jan 06, 2015 at 10:53:35AM +1100, Cyril Bur wrote:
> > On Mon, 2015-01-05 at 11:50 -0500, Don Zickus wrote:
> > > cc'ing Marcelo
> > > 
> > > On Mon, Dec 22, 2014 at 04:06:02PM +1100, Cyril Bur wrote:
> > > > When the hypervisor pauses a virtualised kernel the kernel will observe 
> > > > a jump
> > > > in timebase, this can cause spurious messages from the softlockup 
> > > > detector.
> > > > 
> > > > Whilst these messages are harmless, they are accompanied with a stack 
> > > > trace
> > > > which causes undue concern and more problematically the stack trace in 
> > > > the
> > > > guest has nothing to do with the observed problem and can only be 
> > > > misleading.
> > > > 
> > > > Futhermore, on POWER8 this is completely avoidable with the 
> > > > introduction of
> > > > the Virtual Time Base (VTB) register.
> > > 
> > > Hi Cyril,
> > > 
> > > Your solution seems simple and doesn't disturb the softlockup code as much
> > > as the x86 solution does.  The only small issue I had was the use of
> > > sched_clock instead of local_clock.  I keep forgetting the difference
> > > (unstable clock is the biggest reason I think).
> > My apologies there it appears I stuffed up, local_clock was used
> > initially in the softlockup code, I'll send a v2.
> 
> Thanks!
> 
> > 
> > > Other than that, I am not the biggest fan of putting multiple virtual
> > > guest solutions for the same problem into the watchdog code.  I would
> > > prefer a common solution/framework to leverage.
> > Agreed.
> > 
> > > I have the x86 folks focusing on the steal_time stuff.  It started with
> > > KVM and I believe VMWare is working on utilizing it too (and maybe Xen).
> > I'm not sure I've ever seen this, could you please point me towards
> > something I can look at?
> 
> I am not too familar with it, but the kernel/watchdog.c code has calls to
> kvm_check_and_clear_guest_paused(), which is probably a good place to
> start.
> 
Ah yes that, I did initially have a look at what it does when I
undertook to solve the problem on power and I suppose the two solutions
are similar in that they both just use a virtualised time source. The
similarities stop there though, the paravirtualised clock that x86 uses
provides (as the name of the function implies) a 'was paused' flag.
Obviously the flag isn't something the vtb register on power8 can
provide and since we have a vtb, its preferable to use that.
Perhaps x86 can do something with running_clock?

Regards,

Cyril

> Cheers,
> Don
> 
> > 
> > > Not sure if that is useful or could be incoporated into the power8 code.
> > > Though to be honest I am curious if the steal_time code could be ported to
> > > your solution as it seems the watchdog code could remove all the
> > > steal_time warts.
> > Happy to help sus out the situation here, again, if you could pass on
> > what the x86 guys are working on, thanks.
> > 
> > 
> > Thanks,
> > 
> > Cyril
> > > I have cc'd Marcelo into this discussion as he was the last person I
> > > remember talking with about this problem.
> > > 
> > > Cheers,
> > > Don
> > 
> > 



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: sched_yield() call on Linux Kernel 2.6.39 is not behaving correct

[Mike Galbraith]

On Thu, 2015-01-08 at 10:00 -0500, Yogesh Ahire wrote: 
> Thank you Mike. But I can see there are tasks with same priority and
> are runnable waiting for CPU, following is the output of
> /proc/sched_debug where you can see that the task "symphonyapp"
> continuously calls sched_yield() but there are other tasks which are
> ready to run are not getting CPU and are queued back.

Something terminally bad happened.  With that tasks vruntime (tree-key),
it's gonna try to yield for one hell of a long time before it succeeds.

-Mike

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

Re: [PATCH RFC] usb: chipidea: add support for usb_phy in generic usb2

[Peter Chen]

On Mon, Jan 05, 2015 at 11:09:35AM +0530, Kishon Vijay Abraham I wrote:
> Hi,
> 
> On Sunday 04 January 2015 11:58 AM, Baruch Siach wrote:
> > Signed-off-by: Baruch Siach 
> > ---
> >  drivers/usb/chipidea/ci_hdrc_usb2.c | 5 +
> >  1 file changed, 5 insertions(+)
> > 
> > I'm sending this as RFC as I'm not sure this is the right thing to do. There
> > seems to be a move away from USB specific PHY drivers towards the generic 
> > PHY
> > framework (drivers/phy). The trouble is that my PHY is similar to the mxs 
> > PHY
> > (phy-mxs-usb.c), and like mxs I need the notify_connect/notify_disconnect
> > callbacks. This functionality is not available is the generic PHY
> > framework. Having support for both 'usb-phy' and 'phy' properties (as dwc3
> > seems to do) is particularly bad, since the distinction between the two is a
> > Linux implementation detail that has nothing to do with hardware 
> > description.
> > 
> > So my questions are:
> > 
> >1. Is there a plan to add notifications support to the generic PHY?
> > 
> >2. If not, what are my options?
> 
> extcon framework has notification support. I feel your driver should use the
> extcon framework along with phy framework.
> 
> Adding extcon support in the generic PHY framework is something I have not
> thought through in detail.
> 

Hi Kishon & Felipe

This is also my concern, we will not accept the new usb phy driver using
current usb_phy interface any more, how usb phy specific interfaces are
existed at generic phy, any plans?

> > 
> > Thanks,
> > baruch
> > 
> > diff --git a/drivers/usb/chipidea/ci_hdrc_usb2.c 
> > b/drivers/usb/chipidea/ci_hdrc_usb2.c
> > index 45844c951788..cc3aeb781a57 100644
> > --- a/drivers/usb/chipidea/ci_hdrc_usb2.c
> > +++ b/drivers/usb/chipidea/ci_hdrc_usb2.c
> > @@ -35,11 +35,16 @@ static int ci_hdrc_usb2_probe(struct platform_device 
> > *pdev)
> > struct device *dev = >dev;
> > struct ci_hdrc_usb2_priv *priv;
> > struct ci_hdrc_platform_data *ci_pdata = dev_get_platdata(dev);
> > +   struct usb_phy *usb_phy;
> > int ret;
> >  
> > if (!ci_pdata)
> > ci_pdata = _default_pdata;
> >  
> > +   usb_phy = devm_usb_get_phy_by_phandle(>dev, "usb-phy", 0);
> > +   if (!IS_ERR(usb_phy))
> > +   ci_pdata->usb_phy = usb_phy;
> > +
> > priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
> > if (!priv)
> > return -ENOMEM;
> > 

-- 

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

[PATCHv6 5/5] arm: dts: Add Altera L2 Cache and OCRAM EDAC entries

[tthayer]

From: Thor Thayer 

Adding the device tree entries and bindings needed to support
the Altera L2 cache and On-Chip RAM EDAC. This patch relies upon
an earlier patch to declare and setup On-chip RAM properly.
http://www.spinics.net/lists/devicetree/msg51117.html

Signed-off-by: Thor Thayer 
---
v2: Remove OCRAM declaration and reference prior patch.

v3-5: No Change

v6: Change to nested EDAC device nodes based on community
feedback. Remove L2 syscon. Use consolidated binding.
---
 .../bindings/arm/altera/socfpga-edac.txt   |   46 
 arch/arm/boot/dts/socfpga.dtsi |   20 +
 2 files changed, 66 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/arm/altera/socfpga-edac.txt

diff --git a/Documentation/devicetree/bindings/arm/altera/socfpga-edac.txt 
b/Documentation/devicetree/bindings/arm/altera/socfpga-edac.txt
new file mode 100644
index 000..4bf32e1
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/altera/socfpga-edac.txt
@@ -0,0 +1,46 @@
+Altera SoCFPGA Error Detection and Correction [EDAC]
+
+Required Properties:
+- compatible : Should be "altr,edac"
+- #address-cells: must be 1
+- #size-cells: must be 1
+- ranges : standard definition, should translate from local addresses
+
+Subcomponents:
+
+L2 Cache ECC
+Required Properties:
+- compatible : Should be "altr,l2-edac"
+- reg : Address and size for ECC error interrupt clear registers.
+- interrupts : Should be single bit error interrupt, then double bit error
+   interrupt. Note the rising edge type.
+
+On Chip RAM ECC
+Required Properties:
+- compatible : Should be "altr,ocram-edac"
+- reg : Address and size for ECC error interrupt clear registers.
+- iram : phandle to On-Chip RAM definition.
+- interrupts : Should be single bit error interrupt, then double bit error
+   interrupt. Note the rising edge type.
+
+Example:
+
+   soc_ecc {
+   compatible = "altr,edac";
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges;
+
+   l2edac@ffd08140 {
+   compatible = "altr,l2-edac";
+   reg = <0xffd08140 0x4>;
+   interrupts = <0 36 1>, <0 37 1>;
+   };
+
+   ocramedac@ffd08144 {
+   compatible = "altr,ocram-edac";
+   reg = <0xffd08144 0x4>;
+   iram = <>;
+   interrupts = <0 178 1>, <0 179 1>;
+   };
+   };
diff --git a/arch/arm/boot/dts/socfpga.dtsi b/arch/arm/boot/dts/socfpga.dtsi
index 252c3d1..e546e47 100644
--- a/arch/arm/boot/dts/socfpga.dtsi
+++ b/arch/arm/boot/dts/socfpga.dtsi
@@ -618,6 +618,26 @@
interrupts = <0 39 4>;
};
 
+   soc_ecc {
+   compatible = "altr,edac";
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges;
+
+   l2edac@ffd08140 {
+   compatible = "altr,l2-edac";
+   reg = <0xffd08140 0x4>;
+   interrupts = <0 36 1>, <0 37 1>;
+   };
+
+   ocramedac@ffd08144 {
+   compatible = "altr,ocram-edac";
+   reg = <0xffd08144 0x4>;
+   iram = <>;
+   interrupts = <0 178 1>, <0 179 1>;
+   };
+   };
+
L2: l2-cache@fffef000 {
compatible = "arm,pl310-cache";
reg = <0xfffef000 0x1000>;
-- 
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/

[PATCHv6 1/5] arm: socfpga: Enable L2 Cache ECC on startup.

[tthayer]

From: Thor Thayer 

This patch enables the ECC for L2 cache on machine
startup.  The ECC has to be enabled before data is
is stored in memory otherwise the ECC will fail on
reads.

Signed-off-by: Thor Thayer 
---
v2: Split OCRAM initialization into separate patch.

v3/4: No change

v5: Remove l2cache.h, use io.h instead of clk-provider.h
Make copyright header inclusive. Remove MAINTAINERS entry.

v6: Remove pr_debug() & update year in header.
---
 arch/arm/mach-socfpga/Makefile   |1 +
 arch/arm/mach-socfpga/core.h |2 ++
 arch/arm/mach-socfpga/l2_cache.c |   39 ++
 arch/arm/mach-socfpga/socfpga.c  |4 +++-
 4 files changed, 45 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/mach-socfpga/l2_cache.c

diff --git a/arch/arm/mach-socfpga/Makefile b/arch/arm/mach-socfpga/Makefile
index 6dd7a93..142609e 100644
--- a/arch/arm/mach-socfpga/Makefile
+++ b/arch/arm/mach-socfpga/Makefile
@@ -4,3 +4,4 @@
 
 obj-y  := socfpga.o
 obj-$(CONFIG_SMP)  += headsmp.o platsmp.o
+obj-$(CONFIG_EDAC_ALTERA_L2C) += l2_cache.o
diff --git a/arch/arm/mach-socfpga/core.h b/arch/arm/mach-socfpga/core.h
index 483cb46..28c8a15 100644
--- a/arch/arm/mach-socfpga/core.h
+++ b/arch/arm/mach-socfpga/core.h
@@ -47,4 +47,6 @@ extern unsigned long socfpga_cpu1start_addr;
 
 #define SOCFPGA_SCU_VIRT_BASE   0xfffec000
 
+void socfpga_init_l2_ecc(void);
+
 #endif
diff --git a/arch/arm/mach-socfpga/l2_cache.c b/arch/arm/mach-socfpga/l2_cache.c
new file mode 100644
index 000..047759d
--- /dev/null
+++ b/arch/arm/mach-socfpga/l2_cache.c
@@ -0,0 +1,39 @@
+/*
+ * Copyright Altera Corporation (C) 2015. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program.  If not, see .
+ */
+#include 
+#include 
+#include 
+
+void socfpga_init_l2_ecc(void)
+{
+   struct device_node *np;
+   void __iomem  *mapped_l2_edac_addr;
+
+   np = of_find_compatible_node(NULL, NULL, "altr,l2-edac");
+   if (!np) {
+   pr_err("SOCFPGA: Unable to find altr,l2-edac in dtb\n");
+   return;
+   }
+
+   mapped_l2_edac_addr = of_iomap(np, 0);
+   if (!mapped_l2_edac_addr) {
+   pr_err("SOCFPGA: Unable to find L2 ECC mapping in dtb\n");
+   return;
+   }
+
+   /* Enable ECC */
+   writel(0x01, mapped_l2_edac_addr);
+}
diff --git a/arch/arm/mach-socfpga/socfpga.c b/arch/arm/mach-socfpga/socfpga.c
index 383d61e..ce04313 100644
--- a/arch/arm/mach-socfpga/socfpga.c
+++ b/arch/arm/mach-socfpga/socfpga.c
@@ -1,5 +1,5 @@
 /*
- *  Copyright (C) 2012 Altera Corporation
+ *  Copyright (C) 2012-2015 Altera Corporation
  *
  * This program is free software; you can redistribute it and/or modify
  * it under the terms of the GNU General Public License as published by
@@ -83,6 +83,8 @@ static void __init socfpga_init_irq(void)
 {
irqchip_init();
socfpga_sysmgr_init();
+   if (IS_ENABLED(CONFIG_EDAC_ALTERA_L2C))
+   socfpga_init_l2_ecc();
 }
 
 static void socfpga_cyclone5_restart(enum reboot_mode mode, const char *cmd)
-- 
1.7.9.5

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

Re: [PATCH 0/2] genirq: Make irqchip flags work with stacked irq domains

[Jiang Liu]

On 2015/1/9 1:32, Marc Zyngier wrote:
> With the landing of stacked irq domains in 3.19, we have ended up in a
> situation where we have a stack of IRQ controllers, each with their
> set of flags, but the core code is only able to look at the top-most,
> which is not very helpful. This small series is trying to fix this.
> 
> The first patch converts all access to desc->irq_data.chip->flags to
> using an accessor, without changing anything else. The second patch
> adds some logic to combine these flags as we allocate the interrupts,
> ultimately storing the resulting set as part of the irq_desc
> structure.
> 
> We end-up with a configuration where the flags can either be located
> in the irq_chip structure (non stacked case), or in the irq_desc
> (stacked case). While this isn't really ideal, this gives at least the
> right level of information to the rest of the IRQ framework.
Hi Mark,
By this way, we need to aggregate irq_chip flags for every
irq. How about changing irq_desc_get_chip_flags(struct irq_desc *desc)
to irq_desc_check_chip_flags(struct irq_desc *desc, unsigned int flags)
which dynamically walks the stacked irqchips?
Thanks!
Gerry

> 
> Based on 3.19-rc3, and available at:
> git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git 
> irq/stacked-irqchip-flags
> 
> Marc Zyngier (2):
>   genirq: Abstract access to irq_chip flags
>   genirq: Allow irq_desc to carry the union of stacked irq_chip flags
> 
>  include/linux/irq.h |  4 
>  include/linux/irqdesc.h | 12 
>  kernel/irq/chip.c   | 10 +-
>  kernel/irq/irqdesc.c|  3 +++
>  kernel/irq/irqdomain.c  | 20 +++-
>  kernel/irq/manage.c |  6 +++---
>  kernel/irq/pm.c |  2 +-
>  7 files changed, 47 insertions(+), 10 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 v3 4/4] can: kvaser_usb: Add support for the Usbcan-II family

[Ahmed S. Darwish]

On Thu, Jan 08, 2015 at 12:53:37PM +0100, Marc Kleine-Budde wrote:
> On 01/05/2015 07:31 PM, Ahmed S. Darwish wrote:
> > 

[...]

> > 
> > cf->can_id |= CAN_ERR_CRTL;
> > cf->data[1] = CAN_ERR_CRTL_RX_OVERFLOW;
> > 
> > stats->rx_over_errors++;
> > stats->rx_errors++;
> > 
> > netif_rx(skb);
> > 
> > stats->rx_packets++;
> > stats->rx_bytes += cf->can_dlc;
> 
> Another patch would be not to touch cf after netif_rx(), please move the 
> stats handling before calling netif_rx(). Same applies to the 
> kvaser_usb_rx_can_msg() function.
> 

BTW, is it guaranteed from the SocketCAN stack that netif_rx()
will never return NET_RX_DROPPED? Because if no guarantee
exists, I guess below fragment cannot be completely correct?

stats->rx_packets++;
stats->rx_bytes += cf->can_dlc;
netif_rx(skb);

On the other hand, I don't see evan a single CAN driver checking
netif_rx() return value, so maybe such a check is an overkill...

Thanks,
Darwish
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [LKP] [mm] c8c06efa8b5: -7.6% unixbench.score

[Huang Ying]

On Thu, 2015-01-08 at 18:47 -0800, Davidlohr Bueso wrote:
> On Thu, 2015-01-08 at 10:27 +0800, Huang Ying wrote:
> > FYI, we noticed the below changes on
> > 
> > commit c8c06efa8b552608493b7066c234cfa82c47fcea ("mm: convert i_mmap_mutex 
> > to rwsem")
> > 
> > 
> > testbox/testcase/testparams: lituya/unixbench/performance-execl
> > 
> > 83cde9e8ba95d180  c8c06efa8b552608493b7066c2  
> >   --  
> >  %stddev %change %stddev
> >  \  |\  
> > 721721 ±  1%+303.6%2913110 ±  3%  
> > unixbench.time.voluntary_context_switches
> >  11767 ±  0%  -7.6%  10867 ±  1%  unixbench.score
> 
> I simply cannot reproduce this, not even on a large box.
> 
> mutex (83cde9e8ba95d180):
> run1:
> Execl Throughput   3974.3 lps   (30.0 s, 2 
> samples)
> Voluntary context switches: 377039
> 
> run2:
> Execl Throughput   4115.5 lps   (30.0 s, 2 
> samples)
> Voluntary context switches: 391260
> 
> run3:
> Execl Throughput   4000.2 lps   (30.0 s, 2 
> samples)
> Voluntary context switches: 378674
> 
> rwsem (c8c06efa8b552608493b7066c2):
> run1:
> Execl Throughput   4166.0 lps   (30.0 s, 2 
> samples)
> Voluntary context switches: 385740
> 
> run2:
> Execl Throughput   4115.5 lps   (30.0 s, 2 
> samples)
> Voluntary context switches: 391260
> 
> run3:
> Execl Throughput   4110.5 lps   (29.9 s, 2 
> samples)
> Voluntary context switches: 387053
> 
> Since throughput is in the ballpark, so is the benchmark score (in fact
> the rwsem score is slightly better).
> 
> Is this a one time thing or can you observe it again? Any special things
> you guys are doing when running the benchmark? Here are some things I've
> done: cpu gov set to performance, Unixbench taken from
> (http://byte-unixbench.googlecode.com/files/UnixBench5.1.3.tgz ), used
> default compiler options from unixbench Makefile (that is using the
> solaris 2 option). This pretty much matches the environment info you've
> provided. We've done this lock type comparison exercise plenty of times
> in the past, and I'm a bit surprised to see your numbers.

Is it possible for you to try the reproduce steps in the original
reporting email sent by me?  If you have any question on that steps,
feel free to ask.

Best Regards,
Huang, Ying



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] net: fec: Fix dual ethernet issue in VFxx

[fugang.d...@freescale.com]

From: Stefan Agner  Sent: Friday, January 09, 2015 2:59 AM
> To: Duan Fugang-B38611
> Cc: Bhuvanchandra DV; linux-kernel@vger.kernel.org; Zhou Luwei-B45643;
> l...@karo-electronics.de; Li Frank-B20596; da...@davemloft.net; u.kleine-
> koe...@pengutronix.de; shawn@linaro.org
> Subject: RE: [PATCH] net: fec: Fix dual ethernet issue in VFxx
> 
> On 2015-01-08 04:33, fugang.d...@freescale.com wrote:
> > From: Stefan Agner  Sent: Wednesday, January 07, 2015
> > 6:30 PM
> >> To: Duan Fugang-B38611
> >> Cc: Bhuvanchandra DV; linux-kernel@vger.kernel.org; Zhou
> >> Luwei-B45643; l...@karo-electronics.de; Li Frank-B20596;
> >> da...@davemloft.net
> >> Subject: RE: [PATCH] net: fec: Fix dual ethernet issue in VFxx
> >>
> >> On 2015-01-07 03:11, fugang.d...@freescale.com wrote:
> >> > From: Stefan Agner  Sent: Tuesday, January 06,
> >> > 2015
> >> > 10:52 PM
> >> >> To: Bhuvanchandra DV
> >> >> Cc: linux-kernel@vger.kernel.org; Zhou Luwei-B45643; LW@karo-
> >> >> electronics.de; Li Frank-B20596; Duan Fugang-B38611;
> >> >> da...@davemloft.net
> >> >> Subject: Re: [PATCH] net: fec: Fix dual ethernet issue in VFxx
> >> >>
> >> >> Fwiw, this patch really touches many devices and disables the
> >> >> quirk for some devices, but this is done by intent.
> >> >>
> >> >> The quirk FEC_QUIRK_ENET_MAC was active for i.MX28, i.MX6Q, Vybrid
> >> >> (mvf600-fec) and i.MX6SX. However, the new quirk is only enabled
> >> >> for i.MX28. i.MX6Q doesn't need the quirk since there is one FEC
> >> >> instance only anyway. Vybrid and i.MX6SX have a MDIO bus for each
> instance.
> >> >>
> >> >> Acked-by: Stefan Agner 
> >> >
> >> > We cannot do it by adding a quirk.
> >> > For Vybrid and i.MX6SX and later i.MX7 serial,  there have their
> >> > own MDIO bus for each MAC.
> >> > But, for board design, to save two pin (MDIO, MDC), MAC0 and MAC1
> >> > share the MDIO bus. For example, i.MX6SX sdb/sabreai/arm2 boards
> >> > did like this.
> >>
> >> Hm, so those board use a circumstance which was SoC specific back at
> >> i.MX28 time. IMHO, "Out of luck" the shared MDIO bus is the first one
> >> even for those boards, hence this SoC specific work around still works.
> >> So I still think for the i.MX28 case, the quirk would be a viable
> >> solution, but not for those boards, I agree.
> >>
> >> > So we must add one dts property to distinguish it, not a quirk.
> >>
> >> Just adding a property to the FEC instance who's MDIO bus is in use
> >> seems somewhat archaic. There is a MDIO bus description for other
> >> SoC, do you have in mind how this should look like for fec?
> >>
> >> --
> >> Stefan
> 
> (added Uwe to CC since he added the device tree support for MDIO bus)
> 
> > In general,  MAC2 use MAC1 MDIO bus. Because MAC1 is registered
> > firstly, then register MAC2.
> > We can invent one property like "shared-mii-bus" for MAC1 to tell
> > driver there have other MACs use itself mii bus.
> > Of course, the property needs to add for MAC2 device node to tell
> > driver it will share the MAC1 mii bus.
> 
> There is actually already lot of device tree support for MDIO bus
> description in place (see of_mdiobus_register call in the fec_main
> driver), just the device tree's do not make a lot use of it currently.
> 
> The vf610-twr.dts has both FEC enabled as well as the quirk is enabled in
> the driver for Vybrid. I tested the Tower System Module TWR-SER2 with
> Vybrid. This module has two ethernet PHY's, but _both_ are connected to
> the first RMII's MDIO bus (FEC0). Thanks to the quirk, both ports work
> fine.
> 
> As a side note: Don't be fooled that there are both MDIO buses available
> on the elevator: The module makes use of the MDIO of the first RMII
> signals only, see TWR-SER2 schematic.
> 
> I then disabled the quirk and altered the device tree (patch courtesy of
> Bhuvan):
> 
> diff --git a/arch/arm/boot/dts/vf610-twr.dts b/arch/arm/boot/dts/vf610-
> twr.dts index a0f7621..876c80a 100644
> --- a/arch/arm/boot/dts/vf610-twr.dts
> +++ b/arch/arm/boot/dts/vf610-twr.dts
> @@ -129,13 +129,28 @@
> 
>   {
> phy-mode = "rmii";
> +   phy-handle = <>;
> pinctrl-names = "default";
> pinctrl-0 = <_fec0>;
> status = "okay";
> +
> +   fec0mdio: mdio {
> +   #address-cells = <1>;
> +   #size-cells = <0>;
> +
> +   ethphy0: ethernet-phy@0 {
> +   reg = <0>;
> +   };
> +
> +   ethphy1: ethernet-phy@1 {
> +   reg = <1>;
> +   };
> +   };
>  };
> 
>   {
> phy-mode = "rmii";
> +   phy-handle = <>;
> pinctrl-names = "default";
> pinctrl-0 = <_fec1>;
> status = "okay";
> 
> This worked also fine! Hence we actually already have all device tree
> support needed. For the case we try to solve (using the MDIO bus of each
> RMII), a device tree like this should be sufficient:
> 
>  {
>   phy-mode = "rmii";
>   phy-handle = <>;
> ...
> 
>   fec0mdio: mdio {
>   

Re: [PATCH 1/2] genirq: Abstract access to irq_chip flags

[Jiang Liu]

On 2015/1/9 1:32, Marc Zyngier wrote:
> In order to safely migrate to a cumulative set of flags, start by
> abstracting the way we look at these flags. There is otherwise no
> change in semantics here.

> diff --git a/kernel/irq/manage.c b/kernel/irq/manage.c
> index 8069237..b2a43e0 100644
> --- a/kernel/irq/manage.c
> +++ b/kernel/irq/manage.c
> @@ -491,7 +491,7 @@ static int set_irq_wake_real(unsigned int irq, unsigned 
> int on)
>   struct irq_desc *desc = irq_to_desc(irq);
>   int ret = -ENXIO;
>  
> - if (irq_desc_get_chip(desc)->flags &  IRQCHIP_SKIP_SET_WAKE)
> + if (irq_desc_get_chip_flags(desc) &  IRQCHIP_SKIP_SET_WAKE)
>   return 0;
>  
>   if (desc->irq_data.chip->irq_set_wake)
> @@ -589,7 +589,7 @@ int __irq_set_trigger(struct irq_desc *desc, unsigned int 
> irq,
>  
>   flags &= IRQ_TYPE_SENSE_MASK;
>  
> - if (chip->flags & IRQCHIP_SET_TYPE_MASKED) {
> + if (irq_desc_get_chip_flags(desc) & IRQCHIP_SET_TYPE_MASKED) {
>   if (!irqd_irq_masked(>irq_data))
>   mask_irq(desc);
>   if (!irqd_irq_disabled(>irq_data))
> @@ -1043,7 +1043,7 @@ __setup_irq(unsigned int irq, struct irq_desc *desc, 
> struct irqaction *new)
>* chip flags, so we can avoid the unmask dance at the end of
>* the threaded handler for those.
>*/
> - if (desc->irq_data.chip->flags & IRQCHIP_ONESHOT_SAFE)
> + if (irq_desc_get_chip_flags(desc) & IRQCHIP_ONESHOT_SAFE)
>   new->flags &= ~IRQF_ONESHOT;
>  
>   /*
Hi Mark,
Seems you missed on instance of IRQCHIP_ONESHOT_SAFE in
__setup_irq() as below.
Thanks!
Gerry
-
} else if (new->handler == irq_default_primary_handler &&
   !(desc->irq_data.chip->flags & IRQCHIP_ONESHOT_SAFE)) {
--

> diff --git a/kernel/irq/pm.c b/kernel/irq/pm.c
> index 3ca5325..8ed029d 100644
> --- a/kernel/irq/pm.c
> +++ b/kernel/irq/pm.c
> @@ -88,7 +88,7 @@ static bool suspend_device_irq(struct irq_desc *desc, int 
> irq)
>* chip level. The chip implementation indicates that with
>* IRQCHIP_MASK_ON_SUSPEND.
>*/
> - if (irq_desc_get_chip(desc)->flags & IRQCHIP_MASK_ON_SUSPEND)
> + if (irq_desc_get_chip_flags(desc) & IRQCHIP_MASK_ON_SUSPEND)
>   mask_irq(desc);
>   return true;
>  }
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [LKP] [mm] c8c06efa8b5: -7.6% unixbench.score

[Davidlohr Bueso]

On Thu, 2015-01-08 at 10:27 +0800, Huang Ying wrote:
> FYI, we noticed the below changes on
> 
> commit c8c06efa8b552608493b7066c234cfa82c47fcea ("mm: convert i_mmap_mutex to 
> rwsem")
> 
> 
> testbox/testcase/testparams: lituya/unixbench/performance-execl
> 
> 83cde9e8ba95d180  c8c06efa8b552608493b7066c2  
>   --  
>  %stddev %change %stddev
>  \  |\  
> 721721 ±  1%+303.6%2913110 ±  3%  
> unixbench.time.voluntary_context_switches
>  11767 ±  0%  -7.6%  10867 ±  1%  unixbench.score

I simply cannot reproduce this, not even on a large box.

mutex (83cde9e8ba95d180):
run1:
Execl Throughput   3974.3 lps   (30.0 s, 2 samples)
Voluntary context switches: 377039

run2:
Execl Throughput   4115.5 lps   (30.0 s, 2 samples)
Voluntary context switches: 391260

run3:
Execl Throughput   4000.2 lps   (30.0 s, 2 samples)
Voluntary context switches: 378674

rwsem (c8c06efa8b552608493b7066c2):
run1:
Execl Throughput   4166.0 lps   (30.0 s, 2 samples)
Voluntary context switches: 385740

run2:
Execl Throughput   4115.5 lps   (30.0 s, 2 samples)
Voluntary context switches: 391260

run3:
Execl Throughput   4110.5 lps   (29.9 s, 2 samples)
Voluntary context switches: 387053

Since throughput is in the ballpark, so is the benchmark score (in fact
the rwsem score is slightly better).

Is this a one time thing or can you observe it again? Any special things
you guys are doing when running the benchmark? Here are some things I've
done: cpu gov set to performance, Unixbench taken from
(http://byte-unixbench.googlecode.com/files/UnixBench5.1.3.tgz ), used
default compiler options from unixbench Makefile (that is using the
solaris 2 option). This pretty much matches the environment info you've
provided. We've done this lock type comparison exercise plenty of times
in the past, and I'm a bit surprised to see your numbers.

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 2/2] Chipidea: Set connect-at-fullspeed bit when entering host mode if CI_HDRC_FORCE_FULLSPEED is set in the platform data

[Peter Chen]

On Sun, Jan 04, 2015 at 01:14:59PM +1100, Daniel Tang wrote:
> PORTSC_PFSC is not set on entering host mode which means the USB OTG
> controller will attempt to enumerate USB devices at high speed even when the
> CI_HDRC_FORCE_FULLSPEED flag is set in the platform data.
> 
> This patch ensures it is set right before host mode operations begin if 
> needed.
> 
> Signed-off-by: Daniel Tang 
> ---
>  drivers/usb/chipidea/host.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/usb/chipidea/host.c b/drivers/usb/chipidea/host.c
> index c1694cf..f106d25 100644
> --- a/drivers/usb/chipidea/host.c
> +++ b/drivers/usb/chipidea/host.c
> @@ -132,6 +132,9 @@ static int host_start(struct ci_hdrc *ci)
>   if (ci->platdata->flags & CI_HDRC_DISABLE_STREAMING)
>   hw_write(ci, OP_USBMODE, USBMODE_CI_SDIS, USBMODE_CI_SDIS);
>  
> + if (ci->platdata->flags & CI_HDRC_FORCE_FULLSPEED)
> + hw_write(ci, OP_PORTSC, PORTSC_PFSC, PORTSC_PFSC);
> +
>   return ret;
>  
>  put_hcd:
> -- 
> 2.1.3
> 

looks ok, will push

-- 

Best Regards,
Peter Chen
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [PATCHv3 2/8] devfreq: exynos: Add documentation for generic exynos memory bus frequency driver

[Chanwoo Choi]

Hi Rob,

First of all, thanks for your review.

On 01/09/2015 06:18 AM, Rob Herring wrote:
> Adding Viresh.
> 
> On Wed, Jan 7, 2015 at 7:40 PM, Chanwoo Choi  wrote:
>> This patch adds the documentation for generic exynos memory bus frequency
>> driver.
>>
>> Cc: MyungJoo Ham 
>> Cc: Kyungmin Park 
>> Cc: Kukjin Kim 
>> Signed-off-by: Chanwoo Choi 
>> ---
>>  .../devicetree/bindings/devfreq/exynos-busfreq.txt | 184 
>> +
>>  1 file changed, 184 insertions(+)
>>  create mode 100644 
>> Documentation/devicetree/bindings/devfreq/exynos-busfreq.txt
>>
>> diff --git a/Documentation/devicetree/bindings/devfreq/exynos-busfreq.txt 
>> b/Documentation/devicetree/bindings/devfreq/exynos-busfreq.txt
>> new file mode 100644
>> index 000..c601e88
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/devfreq/exynos-busfreq.txt
>> @@ -0,0 +1,184 @@
>> +
>> +* Generic Exynos Memory Bus device
>> +
>> +The Samsung Exynos SoCs have many memory buses for data transfer between 
>> DRAM
>> +memory and MMC/sub-IP in SoC. Almost Exynos SoCs have the common 
>> architecture
>> +for memory buses. Generally, Exynos SoC express the memory bus by using 
>> memory
>> +bus group and block. The memory bus group has one more memory bus blocks and
>> +OPP table (including frequency and voltage for DVFS), regulator, 
>> devfreq-event
>> +devices. Each memory bus block has a clock for own memory bus speen and
>> +frequency table for DVFS. There are a little different among Exynos SoCs
>> +because each Exynos SoC has the different sub-IP and differnt memory bus.
>> +So, this difference should be specified in devicetree file.
>> +
>> +Required properties for memory bus group:
>> +- compatible: Should be "samsung,exynos-memory-bus".
>> +- operating-points: the OPP table including frequency/voltage information to
>> +  support DVFS (Dynamic Voltage/Frequency Scaling) feature.
>> +- devfreq-events: the devfreq-event device to monitor the curret state of
>> +  memory bus group.
> 
> I don't understand what goes in here.

CPUFREQ use the cpu utilization data to decide the current state of CPU
by CPUFREQ governor. 

Exynos busfreq with DEVFREQ must need the data to monitor the current state
of memory bus of Exynos SoC. So, the devfreq-events provide the current state
of memory bus like as cpu utilization. Exynos busfreq could decide the state
of memory bus by using the devfreq-events.

The summary of devfreq-event device is as following: 
(https://lkml.org/lkml/2015/1/7/795)
: This patch add new devfreq_event class for devfreq_event device which provide
raw data (e.g., memory bus utilization/GPU utilization). This raw data from
devfreq_event data would be used for the governor of devfreq subsystem.
- devfreq_event device : Provide raw data for governor of existing devfreq 
device
- devfreq device   : Monitor device state and change frequency/voltage of 
device
 using the raw data from devfreq_event device

> 
>> +- vdd-mem-supply: the regulator to provide memory bus group with the 
>> voltage.
>> +
>> +Required properties for memory bus block:
>> +- clock-names : the name of clock used by the memory bus, "memory-bus".
>> +- clocks : phandles for clock specified in "clock-names" property.
>> +- #clock-cells: should be 1.
>> +- frequency: the frequency table to support DVFS feature.
> 
> So you have just defined a new OPP table format. We already have one
> and Viresh is working to create a more extendable one. He asked about
> what's needed in devfreq, so Viresh here you go. :)
> 
>> +
>> +Example1 : Memory bus group/block in exynos3250.dtsi are listed below.
>> +   Exynos3250 has two memory bus group (MIF, INT group). MIF memory bus
>> +   group includes one memory bus block between DRAM and eMMC. Also, INT
>> +   memory bus group includes eight memory bus blocks which support each
>> +   sub-IPs between DRAM and sub-IPs.
>> +
>> +   memory_bus_mif: memory_bus@0 {
>> +   compatible = "samsung,exynos-memory-bus";
>> +
>> +   operating-points = <
>> +   40 875000
>> +   20 80
>> +   133000 80
>> +   10 80
>> +   5  80>;
>> +   status = "disabled";
> 
> Why is this not part of the DDR controller or /memory node?

Because the memory bus node in this patch was dependent on only Exynos SoC.
I didn't check the memory bus of another SoC except for Exynos SoC.

> 
>> +   blocks {
>> +   dmc_block: memory_bus_block1 {
>> +   clocks = <_dmc CLK_DIV_DMC>;
>> +   clock-names = "memory-bus";
>> +   frequency = <
>> +   40
>> +   20
>> +   133000
>> +

Re: [PATCH] ovl: Fix condition check for workdir

[hujianyang]

On 2015/1/8 20:41, Seunghun Lee wrote:
> When file system is mounted read-only workdir is not needed.
> 
> Signed-off-by: Seunghun Lee 
> ---
>  fs/overlayfs/super.c | 35 +++
>  1 file changed, 23 insertions(+), 12 deletions(-)
> 
> diff --git a/fs/overlayfs/super.c b/fs/overlayfs/super.c
> index 84f3144..4e50617 100644
> --- a/fs/overlayfs/super.c
> +++ b/fs/overlayfs/super.c
> @@ -30,6 +30,7 @@ struct ovl_config {
>   char *lowerdir;
>   char *upperdir;
>   char *workdir;
> + bool is_rw;
>  };
>  
>  /* private information held for overlayfs's superblock */
> @@ -515,10 +516,11 @@ static int ovl_show_options(struct seq_file *m, struct 
> dentry *dentry)
>   struct ovl_fs *ufs = sb->s_fs_info;
>  
>   seq_printf(m, ",lowerdir=%s", ufs->config.lowerdir);
> - if (ufs->config.upperdir) {
> + if (ufs->config.upperdir)
>   seq_printf(m, ",upperdir=%s", ufs->config.upperdir);
> + if (ufs->config.is_rw)
>   seq_printf(m, ",workdir=%s", ufs->config.workdir);
> - }
> +
>   return 0;
>  }
>  
> @@ -822,16 +824,27 @@ static int ovl_fill_super(struct super_block *sb, void 
> *data, int silent)
>  
>   sb->s_stack_depth = 0;
>   if (ufs->config.upperdir) {
> - /* FIXME: workdir is not needed for a R/O mount */
> + err = ovl_mount_dir(ufs->config.upperdir, );
> + if (err)
> + goto out_free_config;
> +
> + sb->s_stack_depth = upperpath.mnt->mnt_sb->s_stack_depth;
> + }
> +
> + /* If the upper fs is r/o or nonexistent, we mark overlayfs r/o too */
> + if (!upperpath.mnt || (upperpath.mnt->mnt_sb->s_flags & MS_RDONLY)) {
> + ufs->config.is_rw = false;
> + sb->s_flags |= MS_RDONLY;
> + } else {
> + ufs->config.is_rw = true;
> + }

Hi Seunghun,

A partition can be mounted with ro flag. I think workdir is not
needed in this way either.

> +
> + if (ufs->config.is_rw) {
>   if (!ufs->config.workdir) {
>   pr_err("overlayfs: missing 'workdir'\n");
>   goto out_free_config;
>   }
>  
> - err = ovl_mount_dir(ufs->config.upperdir, );
> - if (err)
> - goto out_free_config;
> -
>   err = ovl_mount_dir(ufs->config.workdir, );
>   if (err)
>   goto out_put_upperpath;
> @@ -844,8 +857,8 @@ static int ovl_fill_super(struct super_block *sb, void 
> *data, int silent)
>   pr_err("overlayfs: workdir and upperdir must be 
> separate subtrees\n");
>   goto out_put_workpath;
>   }
> - sb->s_stack_depth = upperpath.mnt->mnt_sb->s_stack_depth;
>   }
> +
>   err = -ENOMEM;
>   lowertmp = kstrdup(ufs->config.lowerdir, GFP_KERNEL);
>   if (!lowertmp)
> @@ -884,7 +897,9 @@ static int ovl_fill_super(struct super_block *sb, void 
> *data, int silent)
>   pr_err("overlayfs: failed to clone upperpath\n");
>   goto out_put_lowerpath;
>   }
> + }
>  
> + if (ufs->config.is_rw) {
>   ufs->workdir = ovl_workdir_create(ufs->upper_mnt, 
> workpath.dentry);
>   err = PTR_ERR(ufs->workdir);
>   if (IS_ERR(ufs->workdir)) {
> @@ -914,10 +929,6 @@ static int ovl_fill_super(struct super_block *sb, void 
> *data, int silent)
>   ufs->numlower++;
>   }
>  
> - /* If the upper fs is r/o or nonexistent, we mark overlayfs r/o too */
> - if (!ufs->upper_mnt || (ufs->upper_mnt->mnt_sb->s_flags & MS_RDONLY))
> - sb->s_flags |= MS_RDONLY;
> -
>   sb->s_d_op = _dentry_operations;
>  
>   err = -ENOMEM;
> 


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v19 01/11] ARM: probes: move all probe code to dedicate directory

[Wang Nan]

On 2015/1/5 19:29, Wang Nan wrote:
> In discussion on LKML (https://lkml.org/lkml/2014/11/28/158), Russell
> King suggests to move all probe related code to arch/arm/probes. This
> patch does the work. Due to dependency on 'arch/arm/kernel/patch.h', this
> patch also moves patch.h to 'arch/arm/include/asm/patch.h', and related
> '#include' directives are also midified to '#include '.
> 
> Following is an overview of this patch:
> 
>  ./arch/arm/kernel/   ./arch/arm/probes/
>  |-- Makefile |-- Makefile
>  |-- probes-arm.c  ==>|-- decode-arm.c
>  |-- probes-arm.h  ==>|-- decode-arm.h
>  |-- probes-thumb.c==>|-- decode-thumb.c
>  |-- probes-thumb.h==>|-- decode-thumb.h
>  |-- probes.c  ==>|-- decode.c
>  |-- probes.h  ==>|-- decode.h
>  ||-- kprobes
>  ||   |-- Makefile
>  |-- kprobes-arm.c ==>|   |-- actions-arm.c
>  |-- kprobes-common.c  ==>|   |-- actions-common.c
>  |-- kprobes-thumb.c   ==>|   |-- actions-thumb.c
>  |-- kprobes.c ==>|   |-- core.c
>  |-- kprobes.h ==>|   |-- core.h
>  |-- kprobes-test-arm.c==>|   |-- test-arm.c
>  |-- kprobes-test.c==>|   |-- test-core.c
>  |-- kprobes-test.h==>|   |-- test-core.h
>  |-- kprobes-test-thumb.c  ==>|   `-- test-thumb.c
>  |`-- uprobes
>  ||-- Makefile
>  |-- uprobes-arm.c ==>|-- actions-arm.c
>  |-- uprobes.c ==>|-- core.c
>  |-- uprobes.h ==>`-- core.h
>  |
>  `-- patch.h   ==>arch/arm/include/asm/patch.h
> 
> Signed-off-by: Wang Nan 
> Acked-by: Masami Hiramatsu 

Hi,

Thanks to Tixy and his test robot, a bug is found in this patch: I forgot to 
change
arch/arm/kernel/kgdb.c, which also includes patch.h. A small code modification
is required.

I have posted a new version of this patch by replying.

Tixy, could you please collect it into your git repository and help me test it
again?

http://lists.infradead.org/pipermail/linux-arm-kernel/2015-January/314520.html

Thanks.


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

[PATCH net-next v2 2/2 RESEND] r8152: check the status before submitting rx

[Hayes Wang]

Don't submit the rx if the device is unplugged, stopped, or
linking down.

Signed-off-by: Hayes Wang 
---
 drivers/net/usb/r8152.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index cd93388..b23426e 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -1789,6 +1789,11 @@ int r8152_submit_rx(struct r8152 *tp, struct rx_agg 
*agg, gfp_t mem_flags)
 {
int ret;
 
+   /* The rx would be stopped, so skip submitting */
+   if (test_bit(RTL8152_UNPLUG, >flags) ||
+   !test_bit(WORK_ENABLE, >flags) || !netif_carrier_ok(tp->netdev))
+   return 0;
+
usb_fill_bulk_urb(agg->urb, tp->udev, usb_rcvbulkpipe(tp->udev, 1),
  agg->head, agg_buf_sz,
  (usb_complete_t)read_bulk_callback, agg);
-- 
2.1.0

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

[PATCH net-next v2 0/2 RESEND] r8152: adjust r8152_submit_rx

[Hayes Wang]

v2:
Replace the patch #1 with "call rtl_start_rx after netif_carrier_on".

For patch #2, replace checking tp->speed with netif_carrier_ok.

v1:
Avoid r8152_submit_rx() from submitting rx during unexpected
moment. This could reduce the time of stopping rx.

For patch #1, the tp->speed should be updated early. Then,
the patch #2 could use it to check the current linking status.

Hayes Wang (2):
  r8152: call rtl_start_rx after netif_carrier_on
  r8152: check the status before submitting rx

 drivers/net/usb/r8152.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

-- 
2.1.0

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

[PATCH net-next v2 1/2 RESEND] r8152: call rtl_start_rx after netif_carrier_on

[Hayes Wang]

Remove rtl_start_rx() from rtl_enable() and put it after calling
netif_carrier_on().

Signed-off-by: Hayes Wang 
---
 drivers/net/usb/r8152.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 57ec23e..cd93388 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -2059,7 +2059,7 @@ static int rtl_enable(struct r8152 *tp)
 
rxdy_gated_en(tp, false);
 
-   return rtl_start_rx(tp);
+   return 0;
 }
 
 static int rtl8152_enable(struct r8152 *tp)
@@ -2874,6 +2874,7 @@ static void set_carrier(struct r8152 *tp)
tp->rtl_ops.enable(tp);
set_bit(RTL8152_SET_RX_MODE, >flags);
netif_carrier_on(netdev);
+   rtl_start_rx(tp);
}
} else {
if (tp->speed & LINK_STATUS) {
-- 
2.1.0

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

[PATCH v20 01/11] ARM: probes: move all probe code to dedicate directory

[Wang Nan]

In discussion on LKML (https://lkml.org/lkml/2014/11/28/158), Russell
King suggests to move all probe related code to arch/arm/probes. This
patch does the work. Due to dependency on 'arch/arm/kernel/patch.h', this
patch also moves patch.h to 'arch/arm/include/asm/patch.h', and related
'#include' directives are also midified to '#include '.

Following is an overview of this patch:

 ./arch/arm/kernel/   ./arch/arm/probes/
 |-- Makefile |-- Makefile
 |-- probes-arm.c  ==>|-- decode-arm.c
 |-- probes-arm.h  ==>|-- decode-arm.h
 |-- probes-thumb.c==>|-- decode-thumb.c
 |-- probes-thumb.h==>|-- decode-thumb.h
 |-- probes.c  ==>|-- decode.c
 |-- probes.h  ==>|-- decode.h
 ||-- kprobes
 ||   |-- Makefile
 |-- kprobes-arm.c ==>|   |-- actions-arm.c
 |-- kprobes-common.c  ==>|   |-- actions-common.c
 |-- kprobes-thumb.c   ==>|   |-- actions-thumb.c
 |-- kprobes.c ==>|   |-- core.c
 |-- kprobes.h ==>|   |-- core.h
 |-- kprobes-test-arm.c==>|   |-- test-arm.c
 |-- kprobes-test.c==>|   |-- test-core.c
 |-- kprobes-test.h==>|   |-- test-core.h
 |-- kprobes-test-thumb.c  ==>|   `-- test-thumb.c
 |`-- uprobes
 ||-- Makefile
 |-- uprobes-arm.c ==>|-- actions-arm.c
 |-- uprobes.c ==>|-- core.c
 |-- uprobes.h ==>`-- core.h
 |
 `-- patch.h   ==>arch/arm/include/asm/patch.h

Signed-off-by: Wang Nan 
Acked-by: Masami Hiramatsu 
---
 arch/arm/Makefile|  1 +
 arch/arm/{kernel => include/asm}/patch.h |  0
 arch/arm/kernel/Makefile | 16 ++--
 arch/arm/kernel/jump_label.c |  2 +-
 arch/arm/kernel/kgdb.c   |  2 +-
 arch/arm/kernel/patch.c  |  3 +--
 arch/arm/probes/Makefile |  7 +++
 arch/arm/{kernel/probes-arm.c => probes/decode-arm.c}|  7 ---
 arch/arm/{kernel/probes-arm.h => probes/decode-arm.h}|  4 +++-
 .../arm/{kernel/probes-thumb.c => probes/decode-thumb.c} |  6 +++---
 .../arm/{kernel/probes-thumb.h => probes/decode-thumb.h} |  4 +++-
 arch/arm/{kernel/probes.c => probes/decode.c}|  4 ++--
 arch/arm/{kernel/probes.h => probes/decode.h}|  2 +-
 arch/arm/probes/kprobes/Makefile | 11 +++
 .../kprobes-arm.c => probes/kprobes/actions-arm.c}   |  6 +++---
 .../kprobes-common.c => probes/kprobes/actions-common.c} |  4 ++--
 .../kprobes-thumb.c => probes/kprobes/actions-thumb.c}   |  6 +++---
 arch/arm/{kernel/kprobes.c => probes/kprobes/core.c} |  8 
 arch/arm/{kernel/kprobes.h => probes/kprobes/core.h} |  3 ++-
 .../kprobes-test-arm.c => probes/kprobes/test-arm.c} |  2 +-
 .../kprobes-test.c => probes/kprobes/test-core.c}|  8 
 .../kprobes-test.h => probes/kprobes/test-core.h}|  2 +-
 .../kprobes-test-thumb.c => probes/kprobes/test-thumb.c} |  4 ++--
 arch/arm/probes/uprobes/Makefile |  1 +
 .../uprobes-arm.c => probes/uprobes/actions-arm.c}   |  6 +++---
 arch/arm/{kernel/uprobes.c => probes/uprobes/core.c} |  6 +++---
 arch/arm/{kernel/uprobes.h => probes/uprobes/core.h} |  0
 27 files changed, 69 insertions(+), 56 deletions(-)
 rename arch/arm/{kernel => include/asm}/patch.h (100%)
 create mode 100644 arch/arm/probes/Makefile
 rename arch/arm/{kernel/probes-arm.c => probes/decode-arm.c} (99%)
 rename arch/arm/{kernel/probes-arm.h => probes/decode-arm.h} (97%)
 rename arch/arm/{kernel/probes-thumb.c => probes/decode-thumb.c} (99%)
 rename arch/arm/{kernel/probes-thumb.h => probes/decode-thumb.h} (97%)
 rename arch/arm/{kernel/probes.c => probes/decode.c} (99%)
 rename arch/arm/{kernel/probes.h => probes/decode.h} (99%)
 create mode 100644 arch/arm/probes/kprobes/Makefile
 rename arch/arm/{kernel/kprobes-arm.c => probes/kprobes/actions-arm.c} (99%)
 rename arch/arm/{kernel/kprobes-common.c => probes/kprobes/actions-common.c} 
(98%)
 rename arch/arm/{kernel/kprobes-thumb.c => probes/kprobes/actions-thumb.c} 
(99%)
 rename arch/arm/{kernel/kprobes.c => probes/kprobes/core.c} (99%)
 rename arch/arm/{kernel/kprobes.h => probes/kprobes/core.h} (96%)
 rename arch/arm/{kernel/kprobes-test-arm.c => probes/kprobes/test-arm.c} (99%)
 rename arch/arm/{kernel/kprobes-test.c => probes/kprobes/test-core.c} (99%)
 rename arch/arm/{kernel/kprobes-test.h => probes/kprobes/test-core.h} (99%)
 rename arch/arm/{kernel/kprobes-test-thumb.c => probes/kprobes/test-thumb.c} 
(99%)
 create mode 100644 arch/arm/probes/uprobes/Makefile
 rename arch/arm/{kernel/uprobes-arm.c => 

Re: [PATCH 0/3] epoll: Add epoll_pwait1 syscall

[Andy Lutomirski]

On Thu, Jan 8, 2015 at 5:52 PM, Fam Zheng  wrote:
> On Thu, 01/08 17:28, Andy Lutomirski wrote:
>> On Thu, Jan 8, 2015 at 5:25 PM, Fam Zheng  wrote:
>> > On Thu, 01/08 09:57, Andy Lutomirski wrote:
>> >> I'd like to see a more ambitious change, since the timer isn't the
>> >> only problem like this.  Specifically, I'd like a syscall that does a
>> >> list of epoll-related things and then waits.  The list of things could
>> >> include, at least:
>> >>
>> >>  - EPOLL_CTL_MOD actions: level-triggered epoll users are likely to
>> >> want to turn on and off their requests for events on a somewhat
>> >> regular basis.
>> >
>> > This sounds good to me.
>> >
>> >>
>> >>  - timerfd_settime actions: this allows a single syscall to wait and
>> >> adjust *both* monotonic and real-time wakeups.
>> >
>> > I'm not sure, doesn't this break orthogonality between epoll and timerfd?
>>
>> Yes.  It's not very elegant, and more elegant ideas are welcome.
>
> What is the purpose of embedding timerfd operation here? Modifying timerfd
> for each poll doesn't sound a common pattern to me.

Setting a timeout is definitely a common pattern, hence this thread.
But the current timeout interface sucks, and people should really use
absolute time.  (My epoll software uses absolute time.)  But then
users need to decide whether to have their timeout based on the
monotonic clock or the realtime clock (or something else entirely).
Some bigger programs may want both -- they may have internal events
queued for certain times and for certain timeouts, and those should
use realtime and monotonic respectively.  Heck, users may also want
separate slack values on those.

Timerfd is the only thing we have right now that is anywhere near
flexible enough.  Obviously if epoll became fancy enough, then we
could do away with the timerfd entirely here.

>
>>
>> >
>> >>
>> >> Would this make sense?  It could look like:
>> >>
>> >> int epoll_mod_and_pwait(int epfd,
>> >>   struct epoll_event *events, int maxevents,
>> >>   struct epoll_command *commands, int ncommands,
>> >>   const sigset_t *sigmask);
>> >
>> > What about flags?
>> >
>>
>> No room.  Maybe it should just be a struct for everything instead of
>> separate args.
>
> Also no room for timeout. A single struct sounds the only way to go.

That's what timerfd is for.  I think it would be a bit weird to
support "timeout" and detailed timerfd control.

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

Re: [f2fs-dev] [PATCH 2/6 v2] f2fs: support goingdown for fs shutdown

[Dave Chinner]

On Thu, Jan 08, 2015 at 05:40:06PM -0800, Jaegeuk Kim wrote:
> Change log from v1:
>  o introduce FS_IOC_GOINGDOWN ioctl
>  o introduce three options: FS_GOING_DOWN_FULLSYNC, FS_GOING_DOWN_METASYNC,
>and FS_GOING_DOWN_NOSYNC
.
> diff --git a/include/uapi/linux/fs.h b/include/uapi/linux/fs.h
> index 3735fa0..f37c699 100644
> --- a/include/uapi/linux/fs.h
> +++ b/include/uapi/linux/fs.h
> @@ -157,6 +157,7 @@ struct inodes_stat_t {
>  #define FIFREEZE _IOWR('X', 119, int)/* Freeze */
>  #define FITHAW   _IOWR('X', 120, int)/* Thaw */
>  #define FITRIM   _IOWR('X', 121, struct fstrim_range)/* Trim 
> */
> +#define FS_IOC_GOINGDOWN _IOR('X', 125, __u32)   /* shutdown */
>  
>  #define  FS_IOC_GETFLAGS _IOR('f', 1, long)
>  #define  FS_IOC_SETFLAGS _IOW('f', 2, long)
> @@ -205,4 +206,11 @@ struct inodes_stat_t {
>  #define SYNC_FILE_RANGE_WRITE2
>  #define SYNC_FILE_RANGE_WAIT_AFTER   4
>  
> +/*
> + * Flags for going down operation used by FS_IOC_GOINGDOWN
> + */
> +#define FS_GOING_DOWN_FULLSYNC   0x0 /* going down with full sync */
> +#define FS_GOING_DOWN_METASYNC   0x1 /* going down with metadata */
> +#define FS_GOING_DOWN_NOSYNC 0x2 /* going down */
> +
>  #endif /* _UAPI_LINUX_FS_H */

This is a separate patch - the first patch in the series should
add these definitions and define the XFS ioctl and flags to use them
so we can clearly see there is no change of the existing user API.
There's no need to change the XFS implementation at all.

The second patch then adds the f2fs implementation.

Cheers,

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

Re: [PATCH] cxl: remove redundant increment of hwirq

[Ian Munsie]

Acked-By: Ian Munsie 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] KVM: ioapic: Record edge-triggered interrupts delivery status.

[Wincy Van]

Ping..

Hi, Paolo, could you please have a look at this patch ?


Thanks,

Wincy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] xfs: use generic FS_IOC_GOINGDOWN for ioctl

[Dave Chinner]

On Thu, Jan 08, 2015 at 05:48:33PM -0800, Jaegeuk Kim wrote:
> Change log from v1:
>  o remove the obsolete options.
> 
> -- >8 --
> 
> This patch uses XFS_IOC_GOINGDOWN for a generic ioctl command, 
> FS_IOC_GOINGDOWN.

Please send the initial rename patch and the XFS changing patches as
a linked series to the same mailing lists.

> Cc: Dave Chinner 
> Signed-off-by: Jaegeuk Kim 
> ---
>  fs/xfs/xfs_fs.h| 9 +
>  fs/xfs/xfs_fsops.c | 6 +++---
>  2 files changed, 4 insertions(+), 11 deletions(-)
> 
> diff --git a/fs/xfs/xfs_fs.h b/fs/xfs/xfs_fs.h
> index 18dc721..a44f528 100644
> --- a/fs/xfs/xfs_fs.h
> +++ b/fs/xfs/xfs_fs.h
> @@ -482,13 +482,6 @@ typedef struct xfs_swapext
>  } xfs_swapext_t;
>  
>  /*
> - * Flags for going down operation
> - */
> -#define XFS_FSOP_GOING_FLAGS_DEFAULT 0x0 /* going down */
> -#define XFS_FSOP_GOING_FLAGS_LOGFLUSH0x1 /* flush log 
> but not data */
> -#define XFS_FSOP_GOING_FLAGS_NOLOGFLUSH  0x2 /* don't flush 
> log nor data */

We are going to need those to remain as we have to support them
forever more.

i.e.

#define XFS_FSOP_GOING_FLAGS_DEFAULTFS_SHUTDOWN_FULLSYNC
#define XFS_FSOP_GOING_FLAGS_LOGFLUSH   FS_SHUTDOWN_METASYNC
#define XFS_FSOP_GOING_FLAGS_NOLOGFLUSH FS_SHUTDOWN_NOSYNC

> -
> -/*
>   * ioctl commands that are used by Linux filesystems
>   */
>  #define XFS_IOC_GETXFLAGSFS_IOC_GETFLAGS
> @@ -555,7 +548,7 @@ typedef struct xfs_swapext
>  #define XFS_IOC_ATTRLIST_BY_HANDLE   _IOW ('X', 122, struct 
> xfs_fsop_attrlist_handlereq)
>  #define XFS_IOC_ATTRMULTI_BY_HANDLE  _IOW ('X', 123, struct 
> xfs_fsop_attrmulti_handlereq)
>  #define XFS_IOC_FSGEOMETRY_IOR ('X', 124, struct xfs_fsop_geom)
> -#define XFS_IOC_GOINGDOWN _IOR ('X', 125, __uint32_t)
> +#define XFS_IOC_GOINGDOWN FS_IOC_GOINGDOWN
>  /*   XFS_IOC_GETFSUUID -- deprecated 140  */

Can we call the new ioctl name FS_IOC_SHUTDOWN?

Cheers,

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

RE: [RFC V6 2/3] arm:add bitrev.h file to support rbit instruction

[Wang, Yalin]

> -Original Message-
> From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk]
> Sent: Friday, January 09, 2015 2:41 AM
> To: Wang, Yalin
> Cc: 'Will Deacon'; 'Ard Biesheuvel'; 'linux-kernel@vger.kernel.org';
> 'akinobu.m...@gmail.com'; 'linux...@kvack.org'; 'Joe Perches'; 'linux-arm-
> ker...@lists.infradead.org'
> Subject: Re: [RFC V6 2/3] arm:add bitrev.h file to support rbit instruction
> 
> On Mon, Nov 17, 2014 at 10:38:58AM +0800, Wang, Yalin wrote:
> > Joe has submitted patches to maintainers, So we need wait for them to
> > be accepted .
> 
> I ran these patches through my autobuilder, and while most builds didn't
> seem to be a problem, the randconfigs found errors:
> 
> /tmp/ccbiuDjS.s:137: Error: selected processor does not support ARM mode
> `rbit r3,r2'
> /tmp/ccbiuDjS.s:145: Error: selected processor does not support ARM mode
> `rbit r0,r1'
> make[4]: *** [drivers/iio/amplifiers/ad8366.o] Error 1
> 
> /tmp/ccFhnoO3.s:6789: Error: selected processor does not support ARM mode
> `rbit r2,r2'
> make[4]: *** [drivers/mtd/devices/docg3.o] Error 1
> 
> /tmp/cckMf2pp.s:239: Error: selected processor does not support ARM mode
> `rbit ip,ip'
> /tmp/cckMf2pp.s:241: Error: selected processor does not support ARM mode
> `rbit r2,r2'
> /tmp/cckMf2pp.s:248: Error: selected processor does not support ARM mode
> `rbit lr,lr'
> /tmp/cckMf2pp.s:250: Error: selected processor does not support ARM mode
> `rbit r3,r3'
> make[5]: *** [drivers/video/fbdev/nvidia/nvidia.o] Error 1
> 
> /tmp/ccTgULsO.s:1151: Error: selected processor does not support ARM mode
> `rbit r1,r1'
> /tmp/ccTgULsO.s:1158: Error: selected processor does not support ARM mode
> `rbit r0,r0'
> /tmp/ccTgULsO.s:1164: Error: selected processor does not support ARM mode
> `rbit ip,ip'
> /tmp/ccTgULsO.s:1166: Error: selected processor does not support ARM mode
> `rbit r3,r3'
> /tmp/ccTgULsO.s:1227: Error: selected processor does not support ARM mode
> `rbit r5,r5'
> /tmp/ccTgULsO.s:1229: Error: selected processor does not support ARM mode
> `rbit lr,lr'
> /tmp/ccTgULsO.s:1236: Error: selected processor does not support ARM mode
> `rbit r0,r0'
> /tmp/ccTgULsO.s:1238: Error: selected processor does not support ARM mode
> `rbit r3,r3'
> make[5]: *** [drivers/video/fbdev/nvidia/nv_accel.o] Error 1
> 
> The root cause is that the kernel being built is supposed to support both
> ARMv7 and ARMv6K CPUs.  However, "rbit" is only available on
> ARMv6T2 (thumb2) and ARMv7, and not plain ARMv6 or ARMv6K CPUs.
> 
In the patch that you applied:
8205/1  add bitrev.h file to support rbit instruction

I have add :
+   select HAVE_ARCH_BITREVERSE if ((CPU_V7M || CPU_V7) && !CPU_V6)

If you build kernel support ARMv6K, should CONFIG_CPU_V6=y, isn't it ?
Then will not build hardware rbit instruction, isn't it ?

Thanks








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

RE: [PATCH v7 3/5] usb: dwc2: add generic PHY framework support for dwc2 usb controler platform driver.

[Paul Zimmerman]

> From: Yunzhi Li [mailto:l...@rock-chips.com]
> Sent: Friday, December 12, 2014 7:10 AM
> 
> Get PHY parameters from devicetree and power off usb PHY during
> system suspend.
> 
> Signed-off-by: Yunzhi Li 
> Acked-by: Paul Zimmerman 
> 
> ---
> 
> Changes in v7: None
> Changes in v6: None
> Changes in v5: None
> Changes in v4: None
> Changes in v3:
> - Fix coding style: both branches of the if() which only one
>   branch of the conditional statement is a single statement
>   should have braces.
> - No need to test dwc2->phy for NULL before calling generic phy
>   APIs.
> 
>  drivers/usb/dwc2/gadget.c   | 33 -
>  drivers/usb/dwc2/platform.c | 36 ++--
>  2 files changed, 46 insertions(+), 23 deletions(-)
> 
> diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
> index 200168e..2601c61 100644
> --- a/drivers/usb/dwc2/gadget.c
> +++ b/drivers/usb/dwc2/gadget.c
> @@ -3410,8 +3410,6 @@ int dwc2_gadget_init(struct dwc2_hsotg *hsotg, int irq)
>  {
>   struct device *dev = hsotg->dev;
>   struct s3c_hsotg_plat *plat = dev->platform_data;
> - struct phy *phy;
> - struct usb_phy *uphy;
>   struct s3c_hsotg_ep *eps;
>   int epnum;
>   int ret;
> @@ -3421,30 +3419,23 @@ int dwc2_gadget_init(struct dwc2_hsotg *hsotg, int 
> irq)
>   hsotg->phyif = GUSBCFG_PHYIF16;
> 
>   /*
> -  * Attempt to find a generic PHY, then look for an old style
> -  * USB PHY, finally fall back to pdata
> +  * If platform probe couldn't find a generic PHY or an old style
> +  * USB PHY, fall back to pdata
>*/
> - phy = devm_phy_get(dev, "usb2-phy");
> - if (IS_ERR(phy)) {
> - uphy = devm_usb_get_phy(dev, USB_PHY_TYPE_USB2);
> - if (IS_ERR(uphy)) {
> - /* Fallback for pdata */
> - plat = dev_get_platdata(dev);
> - if (!plat) {
> - dev_err(dev,
> - "no platform data or transceiver defined\n");
> - return -EPROBE_DEFER;
> - }
> - hsotg->plat = plat;
> - } else
> - hsotg->uphy = uphy;
> - } else {
> - hsotg->phy = phy;
> + if (IS_ERR_OR_NULL(hsotg->phy) && IS_ERR_OR_NULL(hsotg->uphy)) {
> + plat = dev_get_platdata(dev);
> + if (!plat) {
> + dev_err(dev,
> + "no platform data or transceiver defined\n");
> + return -EPROBE_DEFER;

Hi Yunzhi,

Testing Felipe's testing/next branch on an Altera SOCFPGA platform,
the driver never loads because it always returns -EPROBE_DEFER here.
Apparently the SOCFPGA platform does not have any platform data
defined, because dev_get_platdata() always returns NULL.

If I remove the -EPROBE_DEFER return and have it continue on, the
driver works. Reverting the patch also makes it work.

I am testing with the driver built-in. I haven't tried it as a module
yet.

Any ideas? Is the -EPROBE_DEFER return really needed here?

-- 
Paul

> + }
> + hsotg->plat = plat;
> + } else if (hsotg->phy) {
>   /*
>* If using the generic PHY framework, check if the PHY bus
>* width is 8-bit and set the phyif appropriately.
>*/
> - if (phy_get_bus_width(phy) == 8)
> + if (phy_get_bus_width(hsotg->phy) == 8)
>   hsotg->phyif = GUSBCFG_PHYIF8;
>   }
> 
> diff --git a/drivers/usb/dwc2/platform.c b/drivers/usb/dwc2/platform.c
> index 6a795aa..ae095f0 100644
> --- a/drivers/usb/dwc2/platform.c
> +++ b/drivers/usb/dwc2/platform.c
> @@ -155,6 +155,8 @@ static int dwc2_driver_probe(struct platform_device *dev)
>   struct dwc2_core_params defparams;
>   struct dwc2_hsotg *hsotg;
>   struct resource *res;
> + struct phy *phy;
> + struct usb_phy *uphy;
>   int retval;
>   int irq;
> 
> @@ -212,6 +214,24 @@ static int dwc2_driver_probe(struct platform_device *dev)
> 
>   hsotg->dr_mode = of_usb_get_dr_mode(dev->dev.of_node);
> 
> + /*
> +  * Attempt to find a generic PHY, then look for an old style
> +  * USB PHY
> +  */
> + phy = devm_phy_get(>dev, "usb2-phy");
> + if (IS_ERR(phy)) {
> + hsotg->phy = NULL;
> + uphy = devm_usb_get_phy(>dev, USB_PHY_TYPE_USB2);
> + if (IS_ERR(uphy))
> + hsotg->uphy = NULL;
> + else
> + hsotg->uphy = uphy;
> + } else {
> + hsotg->phy = phy;
> + phy_power_on(hsotg->phy);
> + phy_init(hsotg->phy);
> + }
> +
>   spin_lock_init(>lock);
>   mutex_init(>init_mutex);
>   retval = dwc2_gadget_init(hsotg, irq);
> @@ -231,8 +251,15 @@ static int __maybe_unused dwc2_suspend(struct device 
> *dev)
>   struct 

Re: [PATCH 2/2] platform/x86: Add Intel Galileo platform specific setup

[Bryan O'Donoghue]

On 09/01/15 01:00, Ong, Boon Leong wrote:


+static void __init
+intel_galileo_imr_sanity(unsigned long base, unsigned long size) {
+   /* Test zero zero */
+   if (imr_add(0, 0, 0, 0, true) == 0)
+   pr_err(SANITY "zero sized IMR @ 0x\n");


A side-discussion on imr_add():
I would think that we should allow 1KiB IMR setting. Current imr_add() logic
is prohibiting it.


Hi Boon Leong. Ermm, it does allow 1 KiB IMR regions. The following code 
works on the unmodifed V1 driver.


/* Test 1 KiB works */
idx = imr_add(0, IMR_ALIGN, IMR_READ_ACCESS_ALL,
  IMR_WRITE_ACCESS_ALL,false);
if (idx < 0)
pr_err(SANITY "Couldn't add an IMR @ 0x%04x bytes\n", IMR_ALIGN);

Note IMR_ALIGN is 0x400

I'll add that test to the set of sanity tests in V2 just to put your 
mind at ease though.


> So, the 'size' input should be at least 1KiB and imr_add()
> internal logic will adjust 'hi' by -1KiB. Please consider ..

Hmm.

Actually I had a response all typed out for you why I didn't want an API 
to presume to modify the size of my input from the user's POV but, 
thinking about it twice - I agree with you.


V2 will subtract IMR_ALIGN (0x400) bytes from the size.

It's stupid to have to subtract IMR_ALIGN bytes on the input - and 
assumes the user of the API understands how the hardware works - but, of 
course the point of an API is so that the user of it doesn't *have* to 
understand that.


Good call.

--
BOD
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [resend Patch v3 1/2] kaslr: check if kernel location is changed

[Baoquan He]

Hi hpa,

Ping.

Do you have further plan or idea on this issue? Or could you
please merge this patch to fix reported bug for now?

Thanks
Baoquan

On 09/30/14 at 03:08pm, Baoquan He wrote:
> Function handle_relocations() is used to do the relocations handling
> for i686 and kaslr of x86_64. For 32 bit the relocation handling is
> mandotary to perform. For x86_64 only when kaslr is enabled and a
> random kernel location is chosen successfully the relocation handling
> shound be done. However previous implementation only compared the
> kernel loading address and LOAD_PHYSICAL_ADDR where kernel were
> compiled to run at. This would casue system to be exceptional in
> few conditions like when delta between load address and compiled
> address is bigger than what 32bit signed relocations can handle.
> Also there will be limitations that delta can't be too big otherwise
> kernel text virtual addresses will overflow in module address space.
> 
> So in this patch check if kernel location is changed after
> choose_kernel_location() when x86_64. If and only if in x86_64
> and kernel location is changed, we say a kaslr random kernel
> location is chosen, then the relocation handling is needed.
> 
> Signed-off-by: Baoquan He 
> Acked-by: Vivek Goyal 
> Acked-by: Kees Cook 
> Tested-by: Thomas D. 
> Cc: sta...@vger.kernel.org
> ---
>  arch/x86/boot/compressed/misc.c | 26 ++
>  1 file changed, 22 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/x86/boot/compressed/misc.c b/arch/x86/boot/compressed/misc.c
> index 57ab74d..3bb2a17 100644
> --- a/arch/x86/boot/compressed/misc.c
> +++ b/arch/x86/boot/compressed/misc.c
> @@ -230,8 +230,9 @@ static void error(char *x)
>   asm("hlt");
>  }
>  
> -#if CONFIG_X86_NEED_RELOCS
> -static void handle_relocations(void *output, unsigned long output_len)
> +#ifdef CONFIG_X86_NEED_RELOCS
> +static void handle_relocations(void *output_orig, void *output,
> +unsigned long output_len)
>  {
>   int *reloc;
>   unsigned long delta, map, ptr;
> @@ -239,6 +240,20 @@ static void handle_relocations(void *output, unsigned 
> long output_len)
>   unsigned long max_addr = min_addr + output_len;
>  
>   /*
> + * 32bit always requires relocations to be performed. For x86_64,
> + * relocations need to be performed only if kaslr has chosen a
> + * different load address then kernel was originally loaded at.
> + *
> + * If we are here, either kaslr is not configured in or kaslr is disabled
> + * or kaslr has chosen not to change the load location of kernel. Don't
> + * perform any relocations.
> + */
> +#if CONFIG_X86_64
> + if (output_orig == output)
> + return;
> +#endif
> +
> + /*
>* Calculate the delta between where vmlinux was linked to load
>* and where it was actually loaded.
>*/
> @@ -299,7 +314,8 @@ static void handle_relocations(void *output, unsigned 
> long output_len)
>  #endif
>  }
>  #else
> -static inline void handle_relocations(void *output, unsigned long output_len)
> +static inline void handle_relocations(void *output_orig, void *output,
> +   unsigned long output_len)
>  { }
>  #endif
>  
> @@ -360,6 +376,8 @@ asmlinkage __visible void *decompress_kernel(void *rmode, 
> memptr heap,
> unsigned char *output,
> unsigned long output_len)
>  {
> + unsigned char *output_orig = output;
> +
>   real_mode = rmode;
>  
>   sanitize_boot_params(real_mode);
> @@ -402,7 +420,7 @@ asmlinkage __visible void *decompress_kernel(void *rmode, 
> memptr heap,
>   debug_putstr("\nDecompressing Linux... ");
>   decompress(input_data, input_len, NULL, NULL, output, NULL, error);
>   parse_elf(output);
> - handle_relocations(output, output_len);
> + handle_relocations(output_orig, output, output_len);
>   debug_putstr("done.\nBooting the kernel.\n");
>   return output;
>  }
> -- 
> 1.8.5.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: [PATCH] clocksource: tegra: wrap arch/arm-specific sections in CONFIG_ARM

[Paul Walmsley]

Hello Daniel

On Thu, 8 Jan 2015, Daniel Lezcano wrote:

> On 12/09/2014 11:07 PM, Paul Walmsley wrote:
> > 
> > Like several of the other files in drivers/clocksource,
> > tegra20_timer.c contains code that can only compile when CONFIG_ARM is
> > enabled.  This causes obvious problems when trying to compile this
> > code for NVIDIA ARM64-based SoCs, such as Tegra132.  The same timer IP
> > blocks exist, so it seems appropriate to provide support for them.
> > 
> > So until we figure out a better way to partition this code, wrap the
> > delay_timer and persistent_clock support code with preprocessor tests
> > for CONFIG_ARM.
> >
> >  (The delay_timer code should not be needed at all on
> > ARM64 due to the presence of the ARMv8 architected timer.  The
> > persistent_clock support code could become important once power
> > management modes are implemented that turn off the CPU complex.)
> 
> IIUC, the cpuidle driver is not yet ready, right ?
> 
> If it is the case, this driver is not needed yet, no ?

The point of the patch is to allow the hardware drivers selected by 
CONFIG_ARCH_TEGRA to build for an arm64 kernel, just as they build for 
32-bit ARM.  

There's nothing CPUIdle-specific about the patch - that is, this timer can 
be selected as a clockevent and clocksource provider without the use of 
CPUIdle - although low-power PM idle is likely to be a primary use-case.

> Perhaps you can rework a bit this driver in the meantime to have a better fix
> than disabling the code with macros ?

I'm happy to do that, but it would be nice to get the driver compiling 
first for ARM64 :-)

> Otherwise, please try at least to group the code into a minimal set of macros.

So, would it be accurate to say that you would prefer a patch that changes 
more lines of code, but minimizes preprocessor directives, to the current 
patch?

> One comment below.

> > diff --git a/drivers/clocksource/tegra20_timer.c
> > b/drivers/clocksource/tegra20_timer.c
> > index d2616ef16770..83a8f5c9e139 100644
> > --- a/drivers/clocksource/tegra20_timer.c
> > +++ b/drivers/clocksource/tegra20_timer.c
> > @@ -29,8 +29,10 @@
> >   #include 
> >   #include 
> > 
> > +#ifdef CONFIG_ARM
> >   #include 
> >   #include 
> 
> Is smp_twd.h really needed ?
> 
> > +#endif

No, it can be removed.  

Would you be willing to ack or merge a revision of this patch with 

1. the #include  removed

2. a larger number of changed lines, in order to minimize the number of 
new #ifdefs?




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

Darlehen anbieten

Guten Tag,

Ich möchte Ihnen britische Regierung einzuführen diese privaten Kreditvergabe 
Firma, Intelligent Finance, Einarbeitung. Wir geben Kredite an Privatpersonen 
und Unternehmen, wir bieten alle Arten von Darlehen zu einem niedrigen Zinssatz 
von 3%. Wir bieten Darlehen zwischen 10.000 € und mehr. Falls Sie irgendwelche 
finanziellen Schwierigkeiten und brauchen ein Darlehen, bitte kontaktieren Sie 
uns per Telefon oder E-Mail: intelfina...@careceo.com oder Tel: 
+447.045.734.550.

Sie können füllen Sie die folgenden Informationen:

Vollständiger Name:
Geschlecht:
Land und Adresse:
Benötigte Menge:
Dauer:
Tel:

Wir warten auf Ihre prompte Antwort, wenn Sie ein Darlehen benötigen.

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

linux-next: manual merge of the drm-intel tree with the drm-intel-fixes tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the drm-intel tree got a conflict in
drivers/gpu/drm/i915/intel_runtime_pm.c between commit 7f1241ed1a06
("drm/i915: Kill check_power_well() calls") from the drm-intel-fixes
tree and commit e2c719b75c8c ("drm/i915: tame the chattermouth (v2)")
from the drm-intel tree.

I fixed it up (the former removed the code modified by the latter) and
can carry the fix as necessary (no action is required).

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


pgpCIi3Jp8gV3.pgp
Description: OpenPGP digital signature

Re: [PATCH] drm/panel: Add support for AUO b101ean01 panel

[Daniel Kurtz]

Hi hl,

Thanks for submitting this patch.

On Fri, Jan 9, 2015 at 9:47 AM, huang lin  wrote:
>
> The AUO b101ean01 panel is a 10.1" 1280x800 panel,
> which can be supported by the simple panel driver.
>
> Signed-off-by: huang lin 
>
> ---
>
>  drivers/gpu/drm/panel/panel-simple.c | 26 ++
>  1 file changed, 26 insertions(+)
>
> diff --git a/drivers/gpu/drm/panel/panel-simple.c 
> b/drivers/gpu/drm/panel/panel-simple.c
> index e95385b..4f2baee 100644
> --- a/drivers/gpu/drm/panel/panel-simple.c
> +++ b/drivers/gpu/drm/panel/panel-simple.c
> @@ -392,6 +392,29 @@ static const struct panel_desc auo_b116xw03 = {
> },
>  };
>

nit: I think this hunk should go after auo_b101aw03, to match the
(alphabetical) ordering of platform_of_match[].

> +static const struct drm_display_mode auo_b101ean01_mode = {
> +   .clock = 72500,
> +   .hdisplay = 1280,
> +   .hsync_start = 1280 + 200,
> +   .hsync_end = 1280 + 200 + 147,
> +   .htotal = 1280 + 200 + 147 + 32,
> +   .vdisplay = 800,
> +   .vsync_start = 800 + 16,
> +   .vsync_end = 800 + 16 + 4,
> +   .vtotal = 800 + 16 + 4 + 4,
> +   .vrefresh = 60,
> +};
> +
> +static const struct panel_desc auo_b101ean01 = {
> +   .modes = _b101ean01_mode,
> +   .num_modes = 1,
> +   .bpc = 6,
> +   .size = {
> +   .width = 228,
> +   .height = 148,
> +   },
> +};
> +
>  static const struct drm_display_mode auo_b133xtn01_mode = {
> .clock = 69500,
> .hdisplay = 1366,
> @@ -727,6 +750,9 @@ static const struct of_device_id platform_of_match[] = {
> .compatible = "auo,b101aw03",
> .data = _b101aw03,
> }, {
> +   .compatible = "auo,b101ean01",
> +   .data = _b101ean01,
> +   }, {
> .compatible = "auo,b101xtn01",
> .data = _b101xtn01,
> }, {
> --
> 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] drm/panel: Add support for AUO b101ean01 panel

[huang lin]

The AUO b101ean01 panel is a 10.1" 1280x800 panel,
which can be supported by the simple panel driver.

Signed-off-by: huang lin 

---

 drivers/gpu/drm/panel/panel-simple.c | 26 ++
 1 file changed, 26 insertions(+)

diff --git a/drivers/gpu/drm/panel/panel-simple.c 
b/drivers/gpu/drm/panel/panel-simple.c
index e95385b..4f2baee 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -392,6 +392,29 @@ static const struct panel_desc auo_b116xw03 = {
},
 };
 
+static const struct drm_display_mode auo_b101ean01_mode = {
+   .clock = 72500,
+   .hdisplay = 1280,
+   .hsync_start = 1280 + 200,
+   .hsync_end = 1280 + 200 + 147,
+   .htotal = 1280 + 200 + 147 + 32,
+   .vdisplay = 800,
+   .vsync_start = 800 + 16,
+   .vsync_end = 800 + 16 + 4,
+   .vtotal = 800 + 16 + 4 + 4,
+   .vrefresh = 60,
+};
+
+static const struct panel_desc auo_b101ean01 = {
+   .modes = _b101ean01_mode,
+   .num_modes = 1,
+   .bpc = 6,
+   .size = {
+   .width = 228,
+   .height = 148,
+   },
+};
+
 static const struct drm_display_mode auo_b133xtn01_mode = {
.clock = 69500,
.hdisplay = 1366,
@@ -727,6 +750,9 @@ static const struct of_device_id platform_of_match[] = {
.compatible = "auo,b101aw03",
.data = _b101aw03,
}, {
+   .compatible = "auo,b101ean01",
+   .data = _b101ean01,
+   }, {
.compatible = "auo,b101xtn01",
.data = _b101xtn01,
}, {
-- 
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] ASoC: rockchip: i2s: add rockchip_dmaengine_pcm_config

[Jianqun Xu]

This patch makes snd_dmaengine_pcm_register with rockchip_dmaengine_pcm_config,
which configure the parameters of period and buffer match to rockchip DMAC.

===
without rockchip_dmaengine_pcm_config, and test with command -
aplay -D hw:0,0 /tmp/a, there are the error dump:
[  134.899396] dma-pl330 ffb2.dma-controller: fill_queue:2251 Bad Desc(7)
[  134.906270] dma-pl330 ffb2.dma-controller: fill_queue:2251 Bad Desc(8)
[  134.913141] dma-pl330 ffb2.dma-controller: fill_queue:2251 Bad Desc(9)

And bellow sound from DMA debugger:
"I debugged it a little and it looks like what is happening is that requests
which aren't a multiple of burst size * burst length are coming in.  Right
now the i2s block is setting a burst size of 4 and burst length of 4, but
the dmaengine code has no idea about this restriction.  I was able to
eliminate the messages by changing burst length to 1 in the i2s driver.
This fix would always work as long as we're sending a multiple of 4 bytes
(which so far seems to be the case)"

This patch can make the length of dma buffer is aligned to a multiple of burst 
size
and burst length.

Signed-off-by: Jianqun Xu 
---
 sound/soc/rockchip/rockchip_i2s.c | 21 -
 1 file changed, 20 insertions(+), 1 deletion(-)

diff --git a/sound/soc/rockchip/rockchip_i2s.c 
b/sound/soc/rockchip/rockchip_i2s.c
index c74ba37..bdd1021 100644
--- a/sound/soc/rockchip/rockchip_i2s.c
+++ b/sound/soc/rockchip/rockchip_i2s.c
@@ -408,6 +408,24 @@ static const struct regmap_config 
rockchip_i2s_regmap_config = {
.cache_type = REGCACHE_FLAT,
 };
 
+static const struct snd_pcm_hardware rockchip_pcm_hardware = {
+   .info   = SNDRV_PCM_INFO_MMAP |
+ SNDRV_PCM_INFO_MMAP_VALID |
+ SNDRV_PCM_INFO_INTERLEAVED,
+   .period_bytes_min   = 1024,
+   .period_bytes_max   = PAGE_SIZE,
+   .periods_min= 3,
+   .periods_max= 8,
+   .buffer_bytes_max   = 8 * PAGE_SIZE,
+   .fifo_size  = 16,
+};
+
+static const struct snd_dmaengine_pcm_config rockchip_dmaengine_pcm_config = {
+   .pcm_hardware = _pcm_hardware,
+   .prepare_slave_config = snd_dmaengine_pcm_prepare_slave_config,
+   .prealloc_buffer_size = PAGE_SIZE * 8,
+};
+
 static int rockchip_i2s_probe(struct platform_device *pdev)
 {
struct rk_i2s_dev *i2s;
@@ -478,7 +496,8 @@ static int rockchip_i2s_probe(struct platform_device *pdev)
goto err_suspend;
}
 
-   ret = snd_dmaengine_pcm_register(>dev, NULL, 0);
+   ret = snd_dmaengine_pcm_register(>dev,
+_dmaengine_pcm_config, 0);
if (ret) {
dev_err(>dev, "Could not register PCM\n");
goto err_pcm_register;
-- 
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 0/3] epoll: Add epoll_pwait1 syscall

[Fam Zheng]

On Thu, 01/08 17:28, Andy Lutomirski wrote:
> On Thu, Jan 8, 2015 at 5:25 PM, Fam Zheng  wrote:
> > On Thu, 01/08 09:57, Andy Lutomirski wrote:
> >> I'd like to see a more ambitious change, since the timer isn't the
> >> only problem like this.  Specifically, I'd like a syscall that does a
> >> list of epoll-related things and then waits.  The list of things could
> >> include, at least:
> >>
> >>  - EPOLL_CTL_MOD actions: level-triggered epoll users are likely to
> >> want to turn on and off their requests for events on a somewhat
> >> regular basis.
> >
> > This sounds good to me.
> >
> >>
> >>  - timerfd_settime actions: this allows a single syscall to wait and
> >> adjust *both* monotonic and real-time wakeups.
> >
> > I'm not sure, doesn't this break orthogonality between epoll and timerfd?
> 
> Yes.  It's not very elegant, and more elegant ideas are welcome.

What is the purpose of embedding timerfd operation here? Modifying timerfd
for each poll doesn't sound a common pattern to me.

> 
> >
> >>
> >> Would this make sense?  It could look like:
> >>
> >> int epoll_mod_and_pwait(int epfd,
> >>   struct epoll_event *events, int maxevents,
> >>   struct epoll_command *commands, int ncommands,
> >>   const sigset_t *sigmask);
> >
> > What about flags?
> >
> 
> No room.  Maybe it should just be a struct for everything instead of
> separate args.

Also no room for timeout. A single struct sounds the only way to go.

Fam
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] xfs: use generic FS_IOC_GOINGDOWN for ioctl

[Jaegeuk Kim]

Change log from v1:
 o remove the obsolete options.

-- >8 --

This patch uses XFS_IOC_GOINGDOWN for a generic ioctl command, FS_IOC_GOINGDOWN.

Cc: Dave Chinner 
Signed-off-by: Jaegeuk Kim 
---
 fs/xfs/xfs_fs.h| 9 +
 fs/xfs/xfs_fsops.c | 6 +++---
 2 files changed, 4 insertions(+), 11 deletions(-)

diff --git a/fs/xfs/xfs_fs.h b/fs/xfs/xfs_fs.h
index 18dc721..a44f528 100644
--- a/fs/xfs/xfs_fs.h
+++ b/fs/xfs/xfs_fs.h
@@ -482,13 +482,6 @@ typedef struct xfs_swapext
 } xfs_swapext_t;
 
 /*
- * Flags for going down operation
- */
-#define XFS_FSOP_GOING_FLAGS_DEFAULT   0x0 /* going down */
-#define XFS_FSOP_GOING_FLAGS_LOGFLUSH  0x1 /* flush log but not 
data */
-#define XFS_FSOP_GOING_FLAGS_NOLOGFLUSH0x2 /* don't flush 
log nor data */
-
-/*
  * ioctl commands that are used by Linux filesystems
  */
 #define XFS_IOC_GETXFLAGS  FS_IOC_GETFLAGS
@@ -555,7 +548,7 @@ typedef struct xfs_swapext
 #define XFS_IOC_ATTRLIST_BY_HANDLE   _IOW ('X', 122, struct 
xfs_fsop_attrlist_handlereq)
 #define XFS_IOC_ATTRMULTI_BY_HANDLE  _IOW ('X', 123, struct 
xfs_fsop_attrmulti_handlereq)
 #define XFS_IOC_FSGEOMETRY  _IOR ('X', 124, struct xfs_fsop_geom)
-#define XFS_IOC_GOINGDOWN   _IOR ('X', 125, __uint32_t)
+#define XFS_IOC_GOINGDOWN   FS_IOC_GOINGDOWN
 /* XFS_IOC_GETFSUUID -- deprecated 140  */
 
 
diff --git a/fs/xfs/xfs_fsops.c b/fs/xfs/xfs_fsops.c
index fdc6422..f403664 100644
--- a/fs/xfs/xfs_fsops.c
+++ b/fs/xfs/xfs_fsops.c
@@ -793,7 +793,7 @@ xfs_fs_goingdown(
__uint32_t  inflags)
 {
switch (inflags) {
-   case XFS_FSOP_GOING_FLAGS_DEFAULT: {
+   case FS_GOING_DOWN_FULLSYNC: {
struct super_block *sb = freeze_bdev(mp->m_super->s_bdev);
 
if (sb && !IS_ERR(sb)) {
@@ -803,10 +803,10 @@ xfs_fs_goingdown(
 
break;
}
-   case XFS_FSOP_GOING_FLAGS_LOGFLUSH:
+   case FS_GOING_DOWN_METASYNC:
xfs_force_shutdown(mp, SHUTDOWN_FORCE_UMOUNT);
break;
-   case XFS_FSOP_GOING_FLAGS_NOLOGFLUSH:
+   case FS_GOING_DOWN_NOSYNC:
xfs_force_shutdown(mp,
SHUTDOWN_FORCE_UMOUNT | SHUTDOWN_LOG_IO_ERROR);
break;
-- 
2.1.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][RESEND 2] Revert "AUDIT: Allow login in non-init namespaces"

[Calvin Owens]

This reverts 543bc6a1a987 "AUDIT: Allow login in non-init namespaces".

This commit incorrectly assumes that libpam treats -ECONNREFUSED as
an indicator that audit is disabled, and -EPERM or any other error
as a fatal error that prevents the login from continuing.

The opposite is in fact true: -EPERM allows the login to continue,
and -ECONNREFUSED causes it to refuse the login. This behavior has
been unchanged in upstream linux-pam since at least 2008.

Reverting this change allows libpam to again work as expected in
non-init user namespaces.

Signed-off-by: Calvin Owens 
Cc: sta...@vger.kernel.org
---
Relevant code in linux-pam:
https://git.fedorahosted.org/cgit/linux-pam.git/tree/libpam/pam_audit.c#n56

 kernel/audit.c | 12 +---
 1 file changed, 1 insertion(+), 11 deletions(-)

diff --git a/kernel/audit.c b/kernel/audit.c
index 80983df..656e8ce 100644
--- a/kernel/audit.c
+++ b/kernel/audit.c
@@ -640,18 +640,8 @@ static int audit_netlink_ok(struct sk_buff *skb, u16 
msg_type)
int err = 0;
 
/* Only support initial user namespace for now. */
-   /*
-* We return ECONNREFUSED because it tricks userspace into thinking
-* that audit was not configured into the kernel.  Lots of users
-* configure their PAM stack (because that's what the distro does)
-* to reject login if unable to send messages to audit.  If we return
-* ECONNREFUSED the PAM stack thinks the kernel does not have audit
-* configured in and will let login proceed.  If we return EPERM
-* userspace will reject all logins.  This should be removed when we
-* support non init namespaces!!
-*/
if (current_user_ns() != _user_ns)
-   return -ECONNREFUSED;
+   return -EPERM;
 
switch (msg_type) {
case AUDIT_LIST:
-- 
2.1.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] xfs: use generic FS_IOC_GOINGDOWN for ioctl

[Jaegeuk Kim]

This patch uses XFS_IOC_GOINGDOWN for a generic ioctl command, FS_IOC_GOINGDOWN.

Cc: Dave Chinner 
Signed-off-by: Jaegeuk Kim 
---
 fs/xfs/xfs_fs.h| 2 +-
 fs/xfs/xfs_fsops.c | 6 +++---
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/fs/xfs/xfs_fs.h b/fs/xfs/xfs_fs.h
index 18dc721..487a92c 100644
--- a/fs/xfs/xfs_fs.h
+++ b/fs/xfs/xfs_fs.h
@@ -555,7 +555,7 @@ typedef struct xfs_swapext
 #define XFS_IOC_ATTRLIST_BY_HANDLE   _IOW ('X', 122, struct 
xfs_fsop_attrlist_handlereq)
 #define XFS_IOC_ATTRMULTI_BY_HANDLE  _IOW ('X', 123, struct 
xfs_fsop_attrmulti_handlereq)
 #define XFS_IOC_FSGEOMETRY  _IOR ('X', 124, struct xfs_fsop_geom)
-#define XFS_IOC_GOINGDOWN   _IOR ('X', 125, __uint32_t)
+#define XFS_IOC_GOINGDOWN   FS_IOC_GOINGDOWN
 /* XFS_IOC_GETFSUUID -- deprecated 140  */
 
 
diff --git a/fs/xfs/xfs_fsops.c b/fs/xfs/xfs_fsops.c
index fdc6422..f403664 100644
--- a/fs/xfs/xfs_fsops.c
+++ b/fs/xfs/xfs_fsops.c
@@ -793,7 +793,7 @@ xfs_fs_goingdown(
__uint32_t  inflags)
 {
switch (inflags) {
-   case XFS_FSOP_GOING_FLAGS_DEFAULT: {
+   case FS_GOING_DOWN_FULLSYNC: {
struct super_block *sb = freeze_bdev(mp->m_super->s_bdev);
 
if (sb && !IS_ERR(sb)) {
@@ -803,10 +803,10 @@ xfs_fs_goingdown(
 
break;
}
-   case XFS_FSOP_GOING_FLAGS_LOGFLUSH:
+   case FS_GOING_DOWN_METASYNC:
xfs_force_shutdown(mp, SHUTDOWN_FORCE_UMOUNT);
break;
-   case XFS_FSOP_GOING_FLAGS_NOLOGFLUSH:
+   case FS_GOING_DOWN_NOSYNC:
xfs_force_shutdown(mp,
SHUTDOWN_FORCE_UMOUNT | SHUTDOWN_LOG_IO_ERROR);
break;
-- 
2.1.1

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

Re: [f2fs-dev] [PATCH 2/6 v2] f2fs: support goingdown for fs shutdown

[Jaegeuk Kim]

Change log from v1:
 o introduce FS_IOC_GOINGDOWN ioctl
 o introduce three options: FS_GOING_DOWN_FULLSYNC, FS_GOING_DOWN_METASYNC,
   and FS_GOING_DOWN_NOSYNC

This patch add an ioctl to shutdown f2fs, which stops all the further block
writes after this point.

The ioctl, FS_IOC_GOINGDOWN, provides the following three options.

1. FS_GOING_DOWN_FULLSYNC
 : this will flush all the data and dentry blocks, and do checkpoint before
 shutdown.

2. FS_GOING_DOWN_METASYNC
 : this will do checkpoint before shutdown.

3. FS_GOING_DOWN_NOSYNC
 : this will trigger shutdown as is.

Signed-off-by: Jaegeuk Kim 
---
 fs/f2fs/file.c  | 37 +
 include/uapi/linux/fs.h |  8 
 2 files changed, 45 insertions(+)

diff --git a/fs/f2fs/file.c b/fs/f2fs/file.c
index 5df3367..474fb91 100644
--- a/fs/f2fs/file.c
+++ b/fs/f2fs/file.c
@@ -1020,6 +1020,41 @@ static int f2fs_ioc_abort_volatile_write(struct file 
*filp)
return ret;
 }
 
+static int f2fs_ioc_goingdown(struct file *filp, unsigned long arg)
+{
+   struct inode *inode = file_inode(filp);
+   struct f2fs_sb_info *sbi = F2FS_I_SB(inode);
+   struct super_block *sb = sbi->sb;
+   __u32 in;
+
+   if (!capable(CAP_SYS_ADMIN))
+   return -EPERM;
+
+   if (get_user(in, (__u32 __user *)arg))
+   return -EFAULT;
+
+   switch (in) {
+   case FS_GOING_DOWN_FULLSYNC:
+   sb = freeze_bdev(sb->s_bdev);
+   if (sb && !IS_ERR(sb)) {
+   f2fs_stop_checkpoint(sbi);
+   thaw_bdev(sb->s_bdev, sb);
+   }
+   break;
+   case FS_GOING_DOWN_METASYNC:
+   /* do checkpoint only */
+   f2fs_sync_fs(sb, 1);
+   f2fs_stop_checkpoint(sbi);
+   break;
+   case FS_GOING_DOWN_NOSYNC:
+   f2fs_stop_checkpoint(sbi);
+   break;
+   default:
+   return -EINVAL;
+   }
+   return 0;
+}
+
 static int f2fs_ioc_fitrim(struct file *filp, unsigned long arg)
 {
struct inode *inode = file_inode(filp);
@@ -1067,6 +1102,8 @@ long f2fs_ioctl(struct file *filp, unsigned int cmd, 
unsigned long arg)
return f2fs_ioc_release_volatile_write(filp);
case F2FS_IOC_ABORT_VOLATILE_WRITE:
return f2fs_ioc_abort_volatile_write(filp);
+   case FS_IOC_GOINGDOWN:
+   return f2fs_ioc_goingdown(filp, arg);
case FITRIM:
return f2fs_ioc_fitrim(filp, arg);
default:
diff --git a/include/uapi/linux/fs.h b/include/uapi/linux/fs.h
index 3735fa0..f37c699 100644
--- a/include/uapi/linux/fs.h
+++ b/include/uapi/linux/fs.h
@@ -157,6 +157,7 @@ struct inodes_stat_t {
 #define FIFREEZE   _IOWR('X', 119, int)/* Freeze */
 #define FITHAW _IOWR('X', 120, int)/* Thaw */
 #define FITRIM _IOWR('X', 121, struct fstrim_range)/* Trim */
+#define FS_IOC_GOINGDOWN   _IOR('X', 125, __u32)   /* shutdown */
 
 #defineFS_IOC_GETFLAGS _IOR('f', 1, long)
 #defineFS_IOC_SETFLAGS _IOW('f', 2, long)
@@ -205,4 +206,11 @@ struct inodes_stat_t {
 #define SYNC_FILE_RANGE_WRITE  2
 #define SYNC_FILE_RANGE_WAIT_AFTER 4
 
+/*
+ * Flags for going down operation used by FS_IOC_GOINGDOWN
+ */
+#define FS_GOING_DOWN_FULLSYNC 0x0 /* going down with full sync */
+#define FS_GOING_DOWN_METASYNC 0x1 /* going down with metadata */
+#define FS_GOING_DOWN_NOSYNC   0x2 /* going down */
+
 #endif /* _UAPI_LINUX_FS_H */
-- 
2.1.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 v10 4/6] devicetree: backlight: Add new SKY81452 backlight binding

[Gyungoh Yoo]

DT Ack please.

On Wed, Jan 07, 2015 at 11:19:25AM +0900, gyun...@gmail.com wrote:
> From: Gyungoh Yoo 
> 
> Signed-off-by: Gyungoh Yoo 
> Acked-by: Bryan Wu 
> ---
> Changes v10:
> Nothing
> 
> Changes v9:
> Nothing
> 
> Changes v8:
> Renamed property names for backlight with vendor prefix
> Modified gpio-enable property to generic property for GPIO
> Made up the example for backlight DT
> 
> Changes v7:
> Nothing
> 
> Changes v6:
> Nothing
> 
> Changes v5:
> Nothing
> 
> Changes v4:
> Nothing
> 
> Changes v3:
> Nothing
> 
> Changes v2:
> Added reg attribute for I2C slave address
> 
>  .../video/backlight/sky81452-backlight.txt | 29 
> ++
>  1 file changed, 29 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/video/backlight/sky81452-backlight.txt
> 
> diff --git 
> a/Documentation/devicetree/bindings/video/backlight/sky81452-backlight.txt 
> b/Documentation/devicetree/bindings/video/backlight/sky81452-backlight.txt
> new file mode 100644
> index 000..8daebf5
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/video/backlight/sky81452-backlight.txt
> @@ -0,0 +1,29 @@
> +SKY81452-backlight bindings
> +
> +Required properties:
> +- compatible : Must be "skyworks,sky81452-backlight"
> +
> +Optional properties:
> +- name   : Name of backlight device. Default is 
> 'lcd-backlight'.
> +- gpios  : GPIO to use to EN pin.
> + See Documentation/devicetree/bindings/gpio/gpio.txt
> +- skyworks,en-channels   : Enable mask for current sink channel 1 to 6.
> +- skyworks,ignore-pwm: Ignore both PWM input
> +- skyworks,dpwm-mode : Enable DPWM dimming mode, otherwise Analog dimming.
> +- skyworks,phase-shift   : Enable phase shift mode
> +- skyworks,ovp-level : Over-voltage protection level.
> + Should be between 14 or 28V.
> +- skyworks,short-detection-threshold : It should be one of 4, 5, 6 and 7V.
> +- skyworks,current-limit : It should be 2300mA or 2750mA.
> +
> +Example:
> +
> + backlight {
> + compatible = "skyworks,sky81452-backlight";
> + name = "pwm-backlight";
> + skyworks,en-channels = <0x3f>;
> + skyworks,ignore-pwm;
> + skyworks,phase-shift;
> + skyworks,ovp-level = <20>;
> + skyworks,current-limit = <2300>;
> + };
> -- 
> 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 v10 3/6] devicetree: mfd: Add new SKY81452 mfd binding

[Gyungoh Yoo]

DT Ack please.

On Wed, Jan 07, 2015 at 11:19:24AM +0900, gyun...@gmail.com wrote:
> From: Gyungoh Yoo 
> 
> Signed-off-by: Gyungoh Yoo 
> Acked-by: Lee Jones 
> ---
> Changes v10:
> Nothing
> 
> Changes v9:
> Nothing
> 
> Changes v8:
> Made up the example for backlight DT
> 
> Changes v7:
> Nothing
> 
> Changes v6:
> Nothing
> 
> Changes v5:
> Changed DT for regulator : 'lout' node should be defined under 'regulator'
> Removed compatible string from sky81452-regulator driver
> 
> Changes v4:
> Nothing
> 
> Changes v3:
> Nothing
> 
> Changes v2:
> Added reg attribute for I2C slave address
> 
>  Documentation/devicetree/bindings/mfd/sky81452.txt | 36 
> ++
>  1 file changed, 36 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/mfd/sky81452.txt
> 
> diff --git a/Documentation/devicetree/bindings/mfd/sky81452.txt 
> b/Documentation/devicetree/bindings/mfd/sky81452.txt
> new file mode 100644
> index 000..ab71473
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mfd/sky81452.txt
> @@ -0,0 +1,36 @@
> +SKY81452 bindings
> +
> +Required properties:
> +- compatible : Must be "skyworks,sky81452"
> +- reg: I2C slave address
> +
> +Required child nodes:
> +- backlight  : container node for backlight following the binding
> + in video/backlight/sky81452-backlight.txt
> +- regulator  : container node for regulators following the binding
> + in regulator/sky81452-regulator.txt
> +
> +Example:
> +
> + sky81452@2c {
> + compatible = "skyworks,sky81452";
> + reg = <0x2c>;
> +
> + backlight {
> + compatible = "skyworks,sky81452-backlight";
> + name = "pwm-backlight";
> + skyworks,en-channels = <0x3f>;
> + skyworks,ignore-pwm;
> + skyworks,phase-shift;
> + skyworks,ovp-level = <20>;
> + skyworks,current-limit = <2300>;
> + };
> +
> + regulator {
> + lout {
> + regulator-name = "sky81452-lout";
> + regulator-min-microvolt = <450>;
> + regulator-max-microvolt = <800>;
> + };
> + };
> + };
> -- 
> 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 0/3] epoll: Add epoll_pwait1 syscall

[Andy Lutomirski]

On Thu, Jan 8, 2015 at 5:25 PM, Fam Zheng  wrote:
> On Thu, 01/08 09:57, Andy Lutomirski wrote:
>> On Thu, Jan 8, 2015 at 1:12 AM, Miklos Szeredi  wrote:
>> > On Thu, 2015-01-08 at 16:25 +0800, Fam Zheng wrote:
>> >> Applications could use epoll interface when then need to poll a big 
>> >> number of
>> >> files in their main loops, to achieve better performance than ppoll(2). 
>> >> Except
>> >> for one concern: epoll only takes timeout parameters in microseconds, 
>> >> rather
>> >> than nanoseconds.
>> >>
>> >> That is a drawback we should address. For a real case in QEMU, we run 
>> >> into a
>> >> scalability issue with ppoll(2) when many devices are attached to guest, 
>> >> in
>> >> which case many host fds, such as virtual disk images and sockets, need 
>> >> to be
>> >> polled by the main loop. As a result we are looking at switching to 
>> >> epoll, but
>> >> the coarse timeout precision is a trouble, as explained below.
>> >>
>> >> We're already using prctl(PR_SET_TIMERSLACK, 1) which is necessary to 
>> >> implement
>> >> timers in the main loop; and we call ppoll(2) with the next firing timer 
>> >> as
>> >> timeout, so when ppoll(2) returns, we know that we have more work to do 
>> >> (either
>> >> handling IO events, or fire a timer callback). This is natual and 
>> >> efficient,
>> >> except that ppoll(2) itself is slow.
>> >>
>> >> Now that we want to switch to epoll, to speed up the polling. However the 
>> >> timer
>> >> slack setting will be effectively undone, because that way we will have to
>> >> round up the timeout to microseconds honoring timer contract. But 
>> >> consequently,
>> >> this hurts the general responsiveness.
>> >>
>> >> Note: there are two alternatives, without changing kernel:
>> >>
>> >> 1) Leading ppoll(2), with the epollfd only and a nanosecond timeout. It 
>> >> won't
>> >> be slow as one fd is polled. No more scalability issue. And if there are
>> >> events, we know from ppoll(2)'s return, then we do the epoll_wait(2) with
>> >> timeout=0; otherwise, there can't be events for the epoll, skip the 
>> >> following
>> >> epoll_wait and just continue with other work.
>> >>
>> >> 2) Setup and add a timerfd to epoll, then we do epoll_wait(..., 
>> >> timeout=-1).
>> >> The timerfd will hopefully force epoll_wait to return when it timeouts, 
>> >> even if
>> >> no other events have arrived. This will inheritly give us timerfd's 
>> >> precision.
>> >> Note that for each poll, the desired timeout is different because the next
>> >> timer is different, so that, before each epoll_wait(2), there will be a
>> >> timerfd_settime syscall to set it to a proper value.
>> >>
>> >> Unfortunately, both approaches require one more syscall per iteration, 
>> >> compared
>> >> to the original single ppoll(2), cost of which is unneglectable when we 
>> >> talk
>> >> about nanosecond granularity.
>>
>> I'd like to see a more ambitious change, since the timer isn't the
>> only problem like this.  Specifically, I'd like a syscall that does a
>> list of epoll-related things and then waits.  The list of things could
>> include, at least:
>>
>>  - EPOLL_CTL_MOD actions: level-triggered epoll users are likely to
>> want to turn on and off their requests for events on a somewhat
>> regular basis.
>
> This sounds good to me.
>
>>
>>  - timerfd_settime actions: this allows a single syscall to wait and
>> adjust *both* monotonic and real-time wakeups.
>
> I'm not sure, doesn't this break orthogonality between epoll and timerfd?

Yes.  It's not very elegant, and more elegant ideas are welcome.

>
>>
>> Would this make sense?  It could look like:
>>
>> int epoll_mod_and_pwait(int epfd,
>>   struct epoll_event *events, int maxevents,
>>   struct epoll_command *commands, int ncommands,
>>   const sigset_t *sigmask);
>
> What about flags?
>

No room.  Maybe it should just be a struct for everything instead of
separate args.

> Fam



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

Re: [PATCH 0/3] epoll: Add epoll_pwait1 syscall

[Fam Zheng]

On Thu, 01/08 09:57, Andy Lutomirski wrote:
> On Thu, Jan 8, 2015 at 1:12 AM, Miklos Szeredi  wrote:
> > On Thu, 2015-01-08 at 16:25 +0800, Fam Zheng wrote:
> >> Applications could use epoll interface when then need to poll a big number 
> >> of
> >> files in their main loops, to achieve better performance than ppoll(2). 
> >> Except
> >> for one concern: epoll only takes timeout parameters in microseconds, 
> >> rather
> >> than nanoseconds.
> >>
> >> That is a drawback we should address. For a real case in QEMU, we run into 
> >> a
> >> scalability issue with ppoll(2) when many devices are attached to guest, in
> >> which case many host fds, such as virtual disk images and sockets, need to 
> >> be
> >> polled by the main loop. As a result we are looking at switching to epoll, 
> >> but
> >> the coarse timeout precision is a trouble, as explained below.
> >>
> >> We're already using prctl(PR_SET_TIMERSLACK, 1) which is necessary to 
> >> implement
> >> timers in the main loop; and we call ppoll(2) with the next firing timer as
> >> timeout, so when ppoll(2) returns, we know that we have more work to do 
> >> (either
> >> handling IO events, or fire a timer callback). This is natual and 
> >> efficient,
> >> except that ppoll(2) itself is slow.
> >>
> >> Now that we want to switch to epoll, to speed up the polling. However the 
> >> timer
> >> slack setting will be effectively undone, because that way we will have to
> >> round up the timeout to microseconds honoring timer contract. But 
> >> consequently,
> >> this hurts the general responsiveness.
> >>
> >> Note: there are two alternatives, without changing kernel:
> >>
> >> 1) Leading ppoll(2), with the epollfd only and a nanosecond timeout. It 
> >> won't
> >> be slow as one fd is polled. No more scalability issue. And if there are
> >> events, we know from ppoll(2)'s return, then we do the epoll_wait(2) with
> >> timeout=0; otherwise, there can't be events for the epoll, skip the 
> >> following
> >> epoll_wait and just continue with other work.
> >>
> >> 2) Setup and add a timerfd to epoll, then we do epoll_wait(..., 
> >> timeout=-1).
> >> The timerfd will hopefully force epoll_wait to return when it timeouts, 
> >> even if
> >> no other events have arrived. This will inheritly give us timerfd's 
> >> precision.
> >> Note that for each poll, the desired timeout is different because the next
> >> timer is different, so that, before each epoll_wait(2), there will be a
> >> timerfd_settime syscall to set it to a proper value.
> >>
> >> Unfortunately, both approaches require one more syscall per iteration, 
> >> compared
> >> to the original single ppoll(2), cost of which is unneglectable when we 
> >> talk
> >> about nanosecond granularity.
> 
> I'd like to see a more ambitious change, since the timer isn't the
> only problem like this.  Specifically, I'd like a syscall that does a
> list of epoll-related things and then waits.  The list of things could
> include, at least:
> 
>  - EPOLL_CTL_MOD actions: level-triggered epoll users are likely to
> want to turn on and off their requests for events on a somewhat
> regular basis.

This sounds good to me.

> 
>  - timerfd_settime actions: this allows a single syscall to wait and
> adjust *both* monotonic and real-time wakeups.

I'm not sure, doesn't this break orthogonality between epoll and timerfd?

> 
> Would this make sense?  It could look like:
> 
> int epoll_mod_and_pwait(int epfd,
>   struct epoll_event *events, int maxevents,
>   struct epoll_command *commands, int ncommands,
>   const sigset_t *sigmask);

What about flags?

Fam
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: ion: always initialize the free list parameters

[Mitchel Humpherys]

Currently we initialize the heap free_lock and free list size in
ion_heap_init_deferred_free, which is only called when the
ION_HEAP_FLAG_DEFER_FREE heap flag is given.  However, the lock and size
are used in the shrinker path as well as the deferred free path, and we
can register a shrinker *without* enabling deferred freeing.  So, if a
heap provides a shrinker but *doesn't* set the DEFER_FREE flag we will
use these parameters uninitialized (resulting in a spinlock bug and
broken shrinker accounting).

Fix these problems by initializing the free list parameters directly in
ion_device_add_heap, which is always called no matter which heap
features are being used.

Signed-off-by: Mitchel Humpherys 
---
 drivers/staging/android/ion/ion.c  | 3 +++
 drivers/staging/android/ion/ion_heap.c | 2 --
 2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/android/ion/ion.c 
b/drivers/staging/android/ion/ion.c
index 296d347660fc..b8f1c491553e 100644
--- a/drivers/staging/android/ion/ion.c
+++ b/drivers/staging/android/ion/ion.c
@@ -1508,6 +1508,9 @@ void ion_device_add_heap(struct ion_device *dev, struct 
ion_heap *heap)
pr_err("%s: can not add heap with invalid ops struct.\n",
   __func__);
 
+   spin_lock_init(>free_lock);
+   heap->free_list_size = 0;
+
if (heap->flags & ION_HEAP_FLAG_DEFER_FREE)
ion_heap_init_deferred_free(heap);
 
diff --git a/drivers/staging/android/ion/ion_heap.c 
b/drivers/staging/android/ion/ion_heap.c
index 4605e04712aa..fd13d05b538a 100644
--- a/drivers/staging/android/ion/ion_heap.c
+++ b/drivers/staging/android/ion/ion_heap.c
@@ -253,8 +253,6 @@ int ion_heap_init_deferred_free(struct ion_heap *heap)
struct sched_param param = { .sched_priority = 0 };
 
INIT_LIST_HEAD(>free_list);
-   heap->free_list_size = 0;
-   spin_lock_init(>free_lock);
init_waitqueue_head(>waitqueue);
heap->task = kthread_run(ion_heap_deferred_free, heap,
 "%s", heap->name);
-- 
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 1/3] mm/compaction: enhance trace output to know more about compaction internals

[Joonsoo Kim]

On Thu, Jan 08, 2015 at 09:46:27AM +0100, Vlastimil Babka wrote:
> On 01/08/2015 09:18 AM, Joonsoo Kim wrote:
> > On Tue, Jan 06, 2015 at 10:05:39AM +0100, Vlastimil Babka wrote:
> >> On 12/03/2014 08:52 AM, Joonsoo Kim wrote:
> >> > It'd be useful to know where the both scanner is start. And, it also be
> >> > useful to know current range where compaction work. It will help to find
> >> > odd behaviour or problem on compaction.
> >> 
> >> Overall it looks good, just two questions:
> >> 1) Why change the pfn output to hexadecimal with different printf layout 
> >> and
> >> change the variable names and? Is it that better to warrant people having 
> >> to
> >> potentially modify their scripts parsing the old output?
> > 
> > Deciaml output has really bad readability since we manage all pages by order
> > of 2 which is well represented by hexadecimal. With hex output, we can
> > easily notice whether we move out from one pageblock to another one.
> 
> OK. I don't have any strong objection, maybe Mel should comment on this as the
> author of most of the tracepoints? But if it happens, I think converting the 
> old
> tracepoints to new hexadecimal format should be a separate patch from adding 
> the
> new ones.

Okay.

> 
> >> 2) Would it be useful to also print in the mm_compaction_isolate_template 
> >> based
> >> tracepoints, pfn of where the particular scanner left off a block 
> >> prematurely?
> >> It doesn't always match start_pfn + nr_scanned.
> > 
> > With start_pfn and end_pfn, detailed analysis is possible. We can know 
> > pageblock
> > where we actually scan and isolate and how much pages we try in that
> > pageblock and can guess why it doesn't become freepage with pageblock
> > order roughly.
> > 
> > nr_scanned is just different metric. end_pfn don't need to match with
> > start_pfn + nr_scanned.
> 
> Well that's part of my point. end_pfn is the end of the pageblock. nr_scanned
> might be lower than end_pfn - start_pfn, because we terminate in the middle of
> the pageblock. But it might be also lower, because we e.g. skip higher-order
> free pages. So we don't recognize where we terminated early.

Ah... now I see your point and found my mistake. My intention is also to
print terminated pfn rather than end_pfn of pageblock. :/
I will change it to print pfn where we terminate scanning.

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

RE: [PATCH 2/2] platform/x86: Add Intel Galileo platform specific setup

[Ong, Boon Leong]

>Subject: [PATCH 2/2] platform/x86: Add Intel Galileo platform specific setup
>
[snippet removed]

>Since the Quark EFI bringup code configures the system to reset on an IMR
Typo: bring-up

>violation, this means that common operations such as mouting an SD based root
Typo: mounting

[snippet removed]

>+config INTEL_GALILEO
>+  bool "Intel Galileo Platform Support"
>+  depends on X86_32 && PCI
>+  select IOSF_MBI
>+  select IMR
>+  ---help---
>+Intel Galileo platform support. This code is used to tear-down
>+BIOS and Grub Isolated Memory Regions used during bootup.
Missing dash. Should be "boot-up".

[snippet removed]

>diff --git a/drivers/platform/x86/intel_galileo.c
>b/drivers/platform/x86/intel_galileo.c
>new file mode 100644
>index 000..2a555aa
>--- /dev/null
>+++ b/drivers/platform/x86/intel_galileo.c
>@@ -0,0 +1,175 @@
>+/*
>+ * intel_galileo.c - Intel Galileo platform support.
>+ *
>+ * Copyright(c) 2013 Intel Corporation.
>+ * Copyright(c) 2014 Bryan O'Donoghue 
>+ *
>+ * This platform code provides an entry point to do Galileo specific
>+ * setup. Critically IMRs are policed to ensure the EFI provided memory
Critically --> Critical

>+ * map informing the kernel of it's available memory is consistent with
It's --> its

[snippet removed]

>+
>+enum {
>+  GALILEO_UNKNOWN = 0,
>+  GALILEO_QRK_GEN1,
>+  GALILEO_QRK_GEN2,
>+};
Suggest to drop QRK to kill confusion that it is Quark Gen 1 & 2. 

[snippet removed]

>+#ifdef DEBUG
>+#define SANITY "IMR : sanity error "
>+
>+/**
Per coding style, please just use /* and kill the extra * above and below.

>+ * intel_galileo_imr_sanity
>+ * Verify IMR sanity with some simple tests to verify
>+ * overlap, zero sized allocations
>+ *
>+ * @base: Physical base address of the kernel text section
>+ * @size: Extent of kernel memory to be covered from &_text to
>+&_sinittext
>+ * @return: none
>+ */
>+static void __init
>+intel_galileo_imr_sanity(unsigned long base, unsigned long size) {
>+  /* Test zero zero */
>+  if (imr_add(0, 0, 0, 0, true) == 0)
>+  pr_err(SANITY "zero sized IMR @ 0x\n");

A side-discussion on imr_add():
I would think that we should allow 1KiB IMR setting. Current imr_add() logic
is prohibiting it. So, the 'size' input should be at least 1KiB and imr_add()
internal logic will adjust 'hi' by -1KiB. Please consider ..  
  
>+
>+  /* Test overlap */
>+  if (imr_add(base, size, IMR_NON_SMM, IMR_NON_SMM, true) == 0)
>+  pr_err(SANITY "overlapped IMR @ (0x%08lx - 0x%08lx)\n",
>+ base, base + size);
>+
>+  /* Try overlap - IMR_ALIGN */
>+  base = base + size - IMR_ALIGN;
>+  if (imr_add(base, size, IMR_NON_SMM, IMR_NON_SMM, true) == 0)
>+  pr_err(SANITY "overlapped IMR @ (0x%08lx - 0x%08lx)\n",
>+ base, base + size);
>+}
>+#endif
>+
>+/**
>+ * intel_galileo_imr_init
>+ *
>+ * Tear down IMRs used during bootup. BIOS and Grub
boot-up.

>+ * both setup IMRs around compressed kernel, initrd memory
>+ * that need to be removed before the kernel hands out one
>+ * of the IMR encased addresses to a downstream DMA agent
>+ * such as the SD or Ethernet. IMRs on Galileo are setup to
>+ * immediately reset the system on violation - so if you're
>+ * running a root filesystem from SD - you'll need the IMRs
>+ * torn down or you'll find seemingly random resets when using
>+ * your filesystem.
>+ */
>+static void __init intel_galileo_imr_init(void) {
>+  unsigned long base  = virt_to_phys(&_text);
>+  unsigned long size = virt_to_phys(&_sinittext) - base - IMR_ALIGN;
>+  int i, ret;
>+
>+  /* Tear down all existing unlocked IMRs */
>+  for (i = 0; i <= QUARK_X1000_IMR_NUM; i++)
>+  imr_del(i, 0, 0);
>+
>+  /*
>+   * Setup an IMR around the physical extent of the kernel
>+   * Non-SMM mode core read/write from/to kernel physical region.
>+   * IMR locked.
>+   */
>+  ret = imr_add(base, size, IMR_NON_SMM, IMR_NON_SMM, true);
>+  if (ret)
>+  pr_err("Unable to setup IMR for kernel: (%p - %p)\n",
>+  &_text, &__init_begin);
>+  else
>+  pr_info("IMR protect kernel memory: %ldk (%p - %p)\n",
>+  size >> 10, &_text, &__init_begin);
Perhaps we want to be consistent between using __init_begin & _sinittext?

>+#ifdef DEBUG
>+  intel_galileo_imr_sanity(base, size);
>+#endif
>+}
>+
>+/**
>+ * intel_galileo_init
>+ *
>+ * Identify a Galileo Gen1 or Gen2. If found run code to sanitise the
>+ * kernel memory space of IMRs that are inconsistent with the EFI memory
>map.
>+ */
>+static int __init intel_galileo_init(void) {
>+  int ret = 0, type = GALILEO_UNKNOWN;
type is assigned to either GALILEO_GEN1|2 below anyway.
So, we don't need to declare to UNKNOWN?

[snippet removed]
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to 

[PATCH] ALSA: fix emu8000 DRAM sizing for AWE64 Value

[David Flater]

Applicable to any kernel since 2013:

The special case added in commit 1338fc97d07a did not handle the possibility
that the address space on an AWE64 Value would wrap around at 512 KiB.  That
is what it does, so the memory is still not detected on those cards.

Fix that with a logic clean-up that eliminates the need for a special case.
Also log the amount of memory detected at level INFO and add sufficiently
verbose debugging to diagnose any additional faults of this kind.

Tested on unexpanded CT4390 (4 MiB), CT4520 (512 KiB), and CT4380 (512 KiB).
The latter is commonly said to come with 1 MiB of DRAM, but Creative's AWE
Control app agreed that mine has only 512 KiB.  It has the same memory chip
as the CT4520.

Signed-off-by: David Flater 
---
History:
2015-01-08  v1 patch sent to LKML, Alsa Devel and maintainers.

The affected function first appeared in alsa-driver-0.3.0 and was merged in
linux-2.5.5.  Its somewhat different ancestor was in sound/oss/awe_wave.c.

AFAICT, the manufacturer never disclosed the right way to do it.  In the
AWE32 Developer's Information Pack (1994-1996) the RAM sizing function was
implemented in object files with a license that prohibited even disassembly.

 sound/isa/sb/emu8000.c | 127 +
 1 file changed, 76 insertions(+), 51 deletions(-)

diff --git a/sound/isa/sb/emu8000.c b/sound/isa/sb/emu8000.c
index 45fcdff..3aa2250 100644
--- a/sound/isa/sb/emu8000.c
+++ b/sound/isa/sb/emu8000.c
@@ -378,13 +378,13 @@ init_arrays(struct snd_emu8000 *emu)
 static void
 size_dram(struct snd_emu8000 *emu)
 {
-   int i, size, detected_size;
+   int i, size;
+   unsigned short rdback;
 
if (emu->dram_checked)
return;
 
size = 0;
-   detected_size = 0;
 
/* write out a magic number */
snd_emu8000_dma_chan(emu, 0, EMU8000_RAM_WRITE);
@@ -392,55 +392,81 @@ size_dram(struct snd_emu8000 *emu)
EMU8000_SMALW_WRITE(emu, EMU8000_DRAM_OFFSET);
EMU8000_SMLD_WRITE(emu, UNIQUE_ID1);
snd_emu8000_init_fm(emu); /* This must really be here and not 2 lines 
back even */
-
-   while (size < EMU8000_MAX_DRAM) {
-
-   size += 512 * 1024;  /* increment 512kbytes */
-
-   /* Write a unique data on the test address.
-* if the address is out of range, the data is written on
-* 0x20(=EMU8000_DRAM_OFFSET).  Then the id word is
-* changed by this data.
-*/
-   /*snd_emu8000_dma_chan(emu, 0, EMU8000_RAM_WRITE);*/
-   EMU8000_SMALW_WRITE(emu, EMU8000_DRAM_OFFSET + (size>>1));
-   EMU8000_SMLD_WRITE(emu, UNIQUE_ID2);
-   snd_emu8000_write_wait(emu);
-
-   /*
-* read the data on the just written DRAM address
-* if not the same then we have reached the end of ram.
-*/
-   /*snd_emu8000_dma_chan(emu, 0, EMU8000_RAM_READ);*/
-   EMU8000_SMALR_WRITE(emu, EMU8000_DRAM_OFFSET + (size>>1));
-   /*snd_emu8000_read_wait(emu);*/
-   EMU8000_SMLD_READ(emu); /* discard stale data  */
-   if (EMU8000_SMLD_READ(emu) != UNIQUE_ID2)
-   break; /* no memory at this address */
+   snd_emu8000_write_wait(emu);
+
+   /* If that didn't work, we have no RAM at all. */
+   EMU8000_SMALR_WRITE(emu, EMU8000_DRAM_OFFSET);
+   rdback = EMU8000_SMLD_READ(emu);
+   snd_printdd("EMU8000 [0x%lx]: initial discard data = %04hx\n",
+   emu->port1, rdback);
+   rdback = EMU8000_SMLD_READ(emu);
+   snd_printdd("EMU8000 [0x%lx]: initial readback = %04hx\n",
+   emu->port1, rdback);
+   if (rdback == UNIQUE_ID1) {
snd_emu8000_read_wait(emu);
 
/*
-* If it is the same it could be that the address just
-* wraps back to the beginning; so check to see if the
-* initial value has been overwritten.
+* If a write succeeds at the beginning of a 512 KiB page we
+* assume that the whole page is there.
 */
-   EMU8000_SMALR_WRITE(emu, EMU8000_DRAM_OFFSET);
-   EMU8000_SMLD_READ(emu); /* discard stale data  */
-   if (EMU8000_SMLD_READ(emu) != UNIQUE_ID1)
-   break; /* we must have wrapped around */
-   snd_emu8000_read_wait(emu);
-
-   /* Otherwise, it's valid memory. */
-   detected_size = size + 512 * 1024;
-   }
-
-   /* Distinguish 512 KiB from 0. */
-   if (detected_size == 0) {
-   snd_emu8000_read_wait(emu);
-   EMU8000_SMALR_WRITE(emu, EMU8000_DRAM_OFFSET);
-   EMU8000_SMLD_READ(emu); /* discard stale data  */
-   if (EMU8000_SMLD_READ(emu) == UNIQUE_ID1)
-   detected_size = 512 * 1024;
+  

Bodies shaking

[John]

Mama Mia!  
These fem@les are pleasing themselves with machines!!!


http://www.fuckingmachines.com/track/MTYyMTA1MTozOjM,4/

















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