headers
Eric Appleman | 18 May 2013 10:21
Picon

Would like to form a pool of Linux copyright holders for faster GPL enforcement against Anthrax Kernels

Background on Anthrax Kernels and their GPL violation:
http://pastebin.com/X5Cciy03

Would anyone be interested in forming such a pool? I am willing to wait 
years for this to be resolved through certain organizations, but I 
believe we can do better.

Last I checked, I have 1 long-time poster of the gpl-violations list on 
board. Would anyone else like to join? Ideally I'd like to get the LKML 
(which I have CC'd among others) involved so that authors of critical 
Linux components be a part of this. I'm not sure if my defconfig commits 
to Android kernel branches count as contributions, so I'm not going to 
consider myself a Linux contributor unless told otherwise.

This pool would be used in the following manner:

* Formally requesting source for binaries (means to request source is 
actively hidden)
* Formally requesting removal of critical copyrighted code that Linux 
cannot function without
* Informing interested parties with respect to refusals of the above

The CTO of Anthrax's hosting server is very interested in terminating 
Chad Goodman's account. Bullet point #3 might come into effect here.

If this is a bad idea, breaks list etiquette, uses incorrect logic, or 
does not follow the conventions of GPL enforcement, feel free to shoot 
this idea down with utmost prejudice.

- Eric
(Continue reading)

Permalink | Reply | 0 comments |
headers
Laura Abbott | 14 May 2013 21:33

[PATCHv2] arm: mm: Use phys_addr_t properly for ioremap functions

Several of the ioremap functions use unsigned long in places
resulting in truncation if physical addresses greater than
4G are passed in. Change the types of the functions and the
callers accordingly.

Cc: Krzysztof Halasa <khc <at> pm.waw.pl>
Cc: Arnd Bergmann <arnd <at> arndb.de>
Cc: Stephen Boyd <sboyd <at> codeaurora.org>
Cc: Russell King <linux <at> arm.linux.org.uk>
Signed-off-by: Laura Abbott <lauraa <at> codeaurora.org>
---
 arch/arm/include/asm/io.h     |    8 ++++----
 arch/arm/mach-ebsa110/core.c  |    2 +-
 arch/arm/mach-imx/mm-imx3.c   |    2 +-
 arch/arm/mach-iop13xx/io.c    |    2 +-
 arch/arm/mach-ixp4xx/common.c |    2 +-
 arch/arm/mach-msm/common.h    |    2 +-
 arch/arm/mach-msm/io.c        |    2 +-
 arch/arm/mm/ioremap.c         |   10 +++++-----
 arch/arm/mm/nommu.c           |    6 +++---
 9 files changed, 18 insertions(+), 18 deletions(-)

diff --git a/arch/arm/include/asm/io.h b/arch/arm/include/asm/io.h
index 652b560..d070741 100644
--- a/arch/arm/include/asm/io.h
+++ b/arch/arm/include/asm/io.h
 <at>  <at>  -130,16 +130,16  <at>  <at>  static inline u32 __raw_readl(const volatile void __iomem *addr)
  */
 extern void __iomem *__arm_ioremap_pfn_caller(unsigned long, unsigned long,
 	size_t, unsigned int, void *);
(Continue reading)

Permalink | Reply | 2 comments |
headers
Tirupathi Reddy | 14 May 2013 10:29

[PATCH] timer: Don't reinitialize the cpu base lock during CPU_UP_PREPARE

An inactive timer's base can refer to a offline cpu's base.

In the current code, cpu_base's lock is blindly reinitialized
each time a CPU is brought up. If a CPU is brought online
during the period that another thread is trying to modify an
inactive timer on that CPU with holding its timer base lock,
then the lock will be reinitialized under its feet. This leads
to following SPIN_BUG().

<0> BUG: spinlock already unlocked on CPU#3, kworker/u:3/1466
<0> lock: 0xe3ebe000, .magic: dead4ead, .owner: kworker/u:3/1466, .owner_cpu: 1
<4> [<c0013dc4>] (unwind_backtrace+0x0/0x11c) from [<c026e794>] (do_raw_spin_unlock+0x40/0xcc)
<4> [<c026e794>] (do_raw_spin_unlock+0x40/0xcc) from [<c076c160>] (_raw_spin_unlock+0x8/0x30)
<4> [<c076c160>] (_raw_spin_unlock+0x8/0x30) from [<c009b858>] (mod_timer+0x294/0x310)
<4> [<c009b858>] (mod_timer+0x294/0x310) from [<c00a5e04>] (queue_delayed_work_on+0x104/0x120)
<4> [<c00a5e04>] (queue_delayed_work_on+0x104/0x120) from [<c04eae00>] (sdhci_msm_bus_voting+0x88/0x9c)
<4> [<c04eae00>] (sdhci_msm_bus_voting+0x88/0x9c) from [<c04d8780>] (sdhci_disable+0x40/0x48)
<4> [<c04d8780>] (sdhci_disable+0x40/0x48) from [<c04bf300>] (mmc_release_host+0x4c/0xb0)
<4> [<c04bf300>] (mmc_release_host+0x4c/0xb0) from [<c04c7aac>] (mmc_sd_detect+0x90/0xfc)
<4> [<c04c7aac>] (mmc_sd_detect+0x90/0xfc) from [<c04c2504>] (mmc_rescan+0x7c/0x2c4)
<4> [<c04c2504>] (mmc_rescan+0x7c/0x2c4) from [<c00a6a7c>] (process_one_work+0x27c/0x484)
<4> [<c00a6a7c>] (process_one_work+0x27c/0x484) from [<c00a6e94>] (worker_thread+0x210/0x3b0)
<4> [<c00a6e94>] (worker_thread+0x210/0x3b0) from [<c00aad9c>] (kthread+0x80/0x8c)
<4> [<c00aad9c>] (kthread+0x80/0x8c) from [<c000ea80>] (kernel_thread_exit+0x0/0x8)

As an example, this particular crash occurred when CPU #3 is executing
mod_timer() on an inactive timer whose base is refered to offlined CPU #2.
The code locked the timer_base corresponding to CPU #2. Before it could
proceed, CPU #2 came online and reinitialized the spinlock corresponding
to its base. Thus now CPU #3 held a lock which was reinitialized. When
(Continue reading)

Permalink | Reply | 1 comment |
headers
Stephen Boyd | 13 May 2013 21:56

[PATCHv3 0/4] Memory mapped architected timers

This patchset adds support for memory mapped architected timers. We
don't have any other global broadcast timer in our system, so we use the
mmio timer during low power modes. The first patch is the binding.
The next two patches lay some groundwork so that the last patch is simpler.
The final patch adds support for mmio timers.

Patches are based on a patch from Mark that removes the
physical count reading (clocksource: arch_timer: use virtual counter,
message id <1364404312-4427-4-git-send-email-mark.rutland <at> arm.com>).

Updates since v2:
 * Rebased onto v3.10-rc1

Updates since v1:
 * Assigned counter reading function and commented why for arm64
 * Updated DT binding to replace frame-id with frame-number and use status
   property

Stephen Boyd (4):
  Documentation: Add memory mapped ARM architected timer binding
  clocksource: arch_timer: Pass clock event to set_mode callback
  clocksource: arch_timer: Push the read/write wrappers deeper
  clocksource: arch_timer: Add support for memory mapped timers

 .../devicetree/bindings/arm/arch_timer.txt         |  59 ++-
 arch/arm/include/asm/arch_timer.h                  |   5 +-
 arch/arm64/include/asm/arch_timer.h                |   4 +-
 drivers/clocksource/arm_arch_timer.c               | 452 +++++++++++++++++----
 include/clocksource/arm_arch_timer.h               |   4 +-
 5 files changed, 448 insertions(+), 76 deletions(-)
(Continue reading)

Permalink | Reply | 4 comments |
headers
Stephen Boyd | 13 May 2013 21:26

[PATCHv6 00/11] Remove ARM local timer API

In light of Mark Rutland's recent work on divorcing the ARM architected
timers from the ARM local timer API and introducing a generic arch hook for
broadcast it seems that we should remove the local timer API entirely.
Doing so will reduce the architecture dependencies of our timer drivers,
reduce code in ARM core, and simplify timer drivers because they no longer
go through an architecture layer that is essentially a hotplug notifier.

Previous attempts have been made[1] unsuccessfully. I'm hoping this can
be accepted now so that we can clean up the timer drivers that are
used in both UP and SMP situations. Right now these drivers have to ignore
the timer setup callback on the boot CPU to avoid registering clockevents
twice. This is not very symmetric and causes convuluted code that does
the same thing in two places.

Patches based on next-20130418

I'm still looking for Acks/Tested-by on EXYNOS and PRIMA2.

[1] http://article.gmane.org/gmane.linux.ports.arm.kernel/145705

Note: A hotplug notifier is used by both x86 for the apb_timer (see 
apbt_cpuhp_notify) and by metag (see arch_timer_cpu_notify in
metag_generic.c) so this is not new.

Changes since v5:
 * Rebased onto v3.10-rc1
 * Rebase caused minor updates to mct patch

Changes since v4:
 * Rebased onto next-20130418
(Continue reading)

Permalink | Reply | 11 comments |
headers
Dolev Raviv | 12 May 2013 16:22

[PATCH V1 0/8] ufs patch siries

This patch series clusters the latest version of all the UFS patches in the
SCSI mailing list. It gives a stable functional base line for the UFS driver.

It includes the following versions:
> [PATCH 1/2] Documentation: devicetree: Add DT bindings for UFS host
> controller
> [PATCH 2/2] scsi: ufs: Fix the response UPIU length setting
> [PATCH v4 1/6] scsi: ufs: wrap the i/o access operations
> [PATCH v4 2/6] scsi: ufs: amend interrupt configuration
> [PATCH v4 3/6] scsi: ufs: fix interrupt status clears
> [PATCH v4 4/6] scsi: ufs: rework link start-up process
> [PATCH V5 1/1] scsi: ufs: Add support for sending NOP OUT UPIU
> [PATCH V4] scsi: ufs: Set fDeviceInit flag to initiate device
> initialization

But does not include:
> [PATCH v4 5/6] scsi: ufs: add dme configuration primit
> [PATCH v4 6/6] scsi: ufs: add dme control primitives

Dolev Raviv (8):
  Documentation: devicetree: Add DT bindings for UFS host controller
  scsi: ufs: Fix the response UPIU length setting
  scsi: ufs: wrap the i/o access operations
  scsi: ufs: amend interrupt configuration
  scsi: ufs: fix interrupt status clears
  scsi: ufs: rework link start-up process
  scsi: ufs: Add support for sending NOP OUT UPIU
  scsi: ufs: Set fDeviceInit flag to initiate device initialization

 .../devicetree/bindings/ufs/ufshcd-pltfrm.txt      |   16 +
(Continue reading)

Permalink | Reply | 22 comments |
headers
Tanya Brokhman | 12 May 2013 12:34

[PATCH v6 2/3] block: Add API for urgent request handling

This patch add support in block & elevator layers for handling
urgent requests. The decision if a request is urgent or not is taken
by the scheduler. Request is marked as urgent in cmd_flags (by the
scheduler) with a new flag - REQ_URGENT.
Urgent request notification is passed to the underlying
block device driver (eMMC for example). Block device driver may decide to
interrupt the currently running low priority request to serve the new
urgent request. By doing so READ latency is greatly reduced in read&write
collision scenarios.

Note that if the current scheduler doesn't implement the urgent request
mechanism, this code path is never activated.

Signed-off-by: Tatyana Brokhman <tlinder <at> codeaurora.org>

diff --git a/block/blk-core.c b/block/blk-core.c
index adab72d..ac298a4 100644
--- a/block/blk-core.c
+++ b/block/blk-core.c
 <at>  <at>  -296,6 +296,13  <at>  <at>  EXPORT_SYMBOL(blk_sync_queue);
  *    This variant runs the queue whether or not the queue has been
  *    stopped. Must be called with the queue lock held and interrupts
  *    disabled. See also  <at> blk_run_queue.
+ *
+ *    Device driver will be notified of an urgent request
+ *    pending under the following conditions:
+ *    1. The driver and the current scheduler support urgent reques handling
+ *    2. There is an urgent request pending in the scheduler
+ *    3. There isn't already an urgent request in flight, meaning previously
+ *       notified urgent request completed (!q->notified_urgent)
(Continue reading)

Permalink | Reply | 0 comments |
headers
Tirupathi Reddy | 10 May 2013 15:38

[PATCH 1/1] timer: Don't reinitialize the cpu base lock during CPU_UP_PREPARE

An inactive timer's base can refer to a offline cpu's base.

In the current code, cpu_base's lock is blindly reinitialized
each time a CPU is brought up. If a CPU is brought online
during the period that another thread is trying to modify an
inactive timer on that CPU with holding its timer base lock,
then the lock will be reinitialized under its feet. This leads
to following SPIN_BUG().

<0> BUG: spinlock already unlocked on CPU#3, kworker/u:3/1466
<0> lock: 0xe3ebe000, .magic: dead4ead, .owner: kworker/u:3/1466, .owner_cpu: 1
<4> [<c0013dc4>] (unwind_backtrace+0x0/0x11c) from [<c026e794>] (do_raw_spin_unlock+0x40/0xcc)
<4> [<c026e794>] (do_raw_spin_unlock+0x40/0xcc) from [<c076c160>] (_raw_spin_unlock+0x8/0x30)
<4> [<c076c160>] (_raw_spin_unlock+0x8/0x30) from [<c009b858>] (mod_timer+0x294/0x310)
<4> [<c009b858>] (mod_timer+0x294/0x310) from [<c00a5e04>] (queue_delayed_work_on+0x104/0x120)
<4> [<c00a5e04>] (queue_delayed_work_on+0x104/0x120) from [<c04eae00>] (sdhci_msm_bus_voting+0x88/0x9c)
<4> [<c04eae00>] (sdhci_msm_bus_voting+0x88/0x9c) from [<c04d8780>] (sdhci_disable+0x40/0x48)
<4> [<c04d8780>] (sdhci_disable+0x40/0x48) from [<c04bf300>] (mmc_release_host+0x4c/0xb0)
<4> [<c04bf300>] (mmc_release_host+0x4c/0xb0) from [<c04c7aac>] (mmc_sd_detect+0x90/0xfc)
<4> [<c04c7aac>] (mmc_sd_detect+0x90/0xfc) from [<c04c2504>] (mmc_rescan+0x7c/0x2c4)
<4> [<c04c2504>] (mmc_rescan+0x7c/0x2c4) from [<c00a6a7c>] (process_one_work+0x27c/0x484)
<4> [<c00a6a7c>] (process_one_work+0x27c/0x484) from [<c00a6e94>] (worker_thread+0x210/0x3b0)
<4> [<c00a6e94>] (worker_thread+0x210/0x3b0) from [<c00aad9c>] (kthread+0x80/0x8c)
<4> [<c00aad9c>] (kthread+0x80/0x8c) from [<c000ea80>] (kernel_thread_exit+0x0/0x8)

As an example, this particular crash occurred when CPU #3 is executing
mod_timer() on an inactive timer whose base is refered to offlined CPU #2.
The code locked the timer_base corresponding to CPU #2. Before it could
proceed, CPU #2 came online and reinitialized the spinlock corresponding
to its base. Thus now CPU #3 held a lock which was reinitialized. When
(Continue reading)

Permalink | Reply | 0 comments |
headers
Sujit Reddy Thumma | 10 May 2013 06:48

[PATCH 1/2] Documentation: devicetree: Add DT bindings for UFS host controller

Compatible list is used in commit 03b1781 but is not documented.
Add necessary device tree bindings to describe on-chip UFS host
controllers.

Signed-off-by: Sujit Reddy Thumma <sthumma <at> codeaurora.org>
---
 .../devicetree/bindings/ufs/ufshcd-pltfrm.txt      |   16 ++++++++++++++++
 1 files changed, 16 insertions(+), 0 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt

diff --git a/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt b/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt
new file mode 100644
index 0000000..20468b2
--- /dev/null
+++ b/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt
 <at>  <at>  -0,0 +1,16  <at>  <at> 
+* Universal Flash Storage (UFS) Host Controller
+
+UFSHC nodes are defined to describe on-chip UFS host controllers.
+Each UFS controller instance should have its own node.
+
+Required properties:
+- compatible        : compatible list, contains "jedec,ufs-1.1"
+- interrupts        : <interrupt mapping for UFS host controller IRQ>
+- reg               : <registers mapping>
+
+Example:
+	ufshc <at> 0xfc598000 {
+		compatible = "jedec,ufs-1.1";
+		reg = <0xfc598000 0x800>;
(Continue reading)

Permalink | Reply | 1 comment |
headers
Dolev Raviv | 9 May 2013 12:06

[PATCH V4] scsi: ufs: Set fDeviceInit flag to initiate device initialization

Allow UFS device to complete its initialization and accept
SCSI commands by setting fDeviceInit flag. The device may take
time for this operation and hence the host should poll until
fDeviceInit flag is toggled to zero. This step is mandated by
UFS device specification for device initialization completion.

Signed-off-by: Dolev Raviv <draviv <at> codeaurora.org>
Signed-off-by: Sujit Reddy Thumma <sthumma <at> codeaurora.org>

--
Changes for V4:
- Add NULL pointer check
- Changed fix from v3 to bug on since hba can't be null
Changes for V3:
- Fix static checker error
Changes for V2:
- Add the query sending api via SCSI from the original query patch

diff --git a/drivers/scsi/ufs/ufs.h b/drivers/scsi/ufs/ufs.h
index 086ff03..742363d 100644
--- a/drivers/scsi/ufs/ufs.h
+++ b/drivers/scsi/ufs/ufs.h
 <at>  <at>  -107,8 +107,13  <at>  <at>  enum {
 	UPIU_QUERY_FUNC_STANDARD_WRITE_REQUEST = 0x81,
 };

+/* Flag idn for Query Requests*/
+enum flag_idn {
+	QUERY_FLAG_IDN_FDEVICEINIT = 0x01,
+};
(Continue reading)

Permalink | Reply | 0 comments |
headers
Saravana Kannan | 9 May 2013 07:18

[PATCH 0/3] Fix disable of unused clk/regulator with deferred probe

Clock and regulator frameworks have support for disabling unused clocks and
regulators at system init to save power when bootloaders leave them in a less
than desirable state. If no driver has requested for a clock/regulator to be
ON by the time kernel init reaches late_initcall level, they were considered
unused.

This worked well/good enough for compiled in drivers before deferred probe
was introduced. But with deferred probe, it's quite likely that devices that
match with compiled in drivers will continue to probe well past late_initcall
(at least as far as I can understand). So, we need to wait for deferred
probing during kernel init to complete before we do the disable of unused
clocks/regulators.

If there's a better or more obvious solution, I'm all ears. Another approach
would have been to add a "probe_done_initcall" level. But that seems overkill
and I don't think adding yet another initcall level is a great idea.

Thanks,
Saravana

Saravana Kannan (3):
  driver core: Add API to wait for deferred probe to complete during
    init
  clk: Disable unused clocks after deferred probing is done
  regulator: core: Disable unused regulators after deferred probing is
    done

 drivers/base/dd.c        |    8 ++++++++
 drivers/clk/clk.c        |    4 +++-
 drivers/regulator/core.c |    4 +++-
(Continue reading)

Permalink | Reply | 24 comments |

Gmane