linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* RE:
@ 2017-07-31 23:46 TD CREDIT
  0 siblings, 0 replies; 414+ messages in thread
From: TD CREDIT @ 2017-07-31 23:46 UTC (permalink / raw)
  To: Recipients

DO YOU NEED ANY KIND OF LOAN CREDIT ASSISTANCE? IF YES,EMAIL US FOR MORE INFO.

---
This email is free from viruses and malware because avast! Antivirus protection is active.
http://www.avast.com

^ permalink raw reply	[flat|nested] 414+ messages in thread
* (no subject)
@ 2024-03-07  6:07 KR Kim
  2024-03-07  8:01 ` Miquel Raynal
  0 siblings, 1 reply; 414+ messages in thread
From: KR Kim @ 2024-03-07  6:07 UTC (permalink / raw)
  To: miquel.raynal, richard, vigneshr, mmkurbanov, ddrokosov, gch981213
  Cc: kr.kim, michael, broonie, mika.westerberg, acelan.kao,
	linux-kernel, linux-mtd, moh.sardi, changsub.shim

Feat: Add SkyHigh Memory Patch code

Add SPI Nand Patch code of SkyHigh Memory
- Add company dependent code with 'skyhigh.c'
- Insert into 'core.c' so that 'always ECC on'

commit 6061b97a830af8cb5fd0917e833e779451f9046a (HEAD -> master)
Author: KR Kim <kr.kim@skyhighmemory.com>
Date:   Thu Mar 7 13:24:11 2024 +0900

    SPI Nand Patch code of SkyHigh Momory

    Signed-off-by: KR Kim <kr.kim@skyhighmemory.com>

From 6061b97a830af8cb5fd0917e833e779451f9046a Mon Sep 17 00:00:00 2001
From: KR Kim <kr.kim@skyhighmemory.com>
Date: Thu, 7 Mar 2024 13:24:11 +0900
Subject: [PATCH] SPI Nand Patch code of SkyHigh Memory

---
 drivers/mtd/nand/spi/Makefile  |   2 +-
 drivers/mtd/nand/spi/core.c    |   7 +-
 drivers/mtd/nand/spi/skyhigh.c | 155 +++++++++++++++++++++++++++++++++
 include/linux/mtd/spinand.h    |   3 +
 4 files changed, 165 insertions(+), 2 deletions(-)
 mode change 100644 => 100755 drivers/mtd/nand/spi/Makefile
 mode change 100644 => 100755 drivers/mtd/nand/spi/core.c
 create mode 100644 drivers/mtd/nand/spi/skyhigh.c
 mode change 100644 => 100755 include/linux/mtd/spinand.h

diff --git a/drivers/mtd/nand/spi/Makefile b/drivers/mtd/nand/spi/Makefile
old mode 100644
new mode 100755
index 19cc77288ebb..1e61ab21893a
--- a/drivers/mtd/nand/spi/Makefile
+++ b/drivers/mtd/nand/spi/Makefile
@@ -1,4 +1,4 @@
 # SPDX-License-Identifier: GPL-2.0
 spinand-objs := core.o alliancememory.o ato.o esmt.o foresee.o gigadevice.o macronix.o
-spinand-objs += micron.o paragon.o toshiba.o winbond.o xtx.o
+spinand-objs += micron.o paragon.o skyhigh.o toshiba.o winbond.o xtx.o
 obj-$(CONFIG_MTD_SPI_NAND) += spinand.o
diff --git a/drivers/mtd/nand/spi/core.c b/drivers/mtd/nand/spi/core.c
old mode 100644
new mode 100755
index e0b6715e5dfe..e3f0a7544ba4
--- a/drivers/mtd/nand/spi/core.c
+++ b/drivers/mtd/nand/spi/core.c
@@ -34,7 +34,7 @@ static int spinand_read_reg_op(struct spinand_device *spinand, u8 reg, u8 *val)
 	return 0;
 }
 
-static int spinand_write_reg_op(struct spinand_device *spinand, u8 reg, u8 val)
+int spinand_write_reg_op(struct spinand_device *spinand, u8 reg, u8 val)
 {
 	struct spi_mem_op op = SPINAND_SET_FEATURE_OP(reg,
 						      spinand->scratchbuf);
@@ -196,6 +196,10 @@ static int spinand_init_quad_enable(struct spinand_device *spinand)
 static int spinand_ecc_enable(struct spinand_device *spinand,
 			      bool enable)
 {
+	/* SHM : always ECC enable */
+	if (spinand->flags & SPINAND_ON_DIE_ECC_MANDATORY)
+		return 0;
+
 	return spinand_upd_cfg(spinand, CFG_ECC_ENABLE,
 			       enable ? CFG_ECC_ENABLE : 0);
 }
@@ -945,6 +949,7 @@ static const struct spinand_manufacturer *spinand_manufacturers[] = {
 	&macronix_spinand_manufacturer,
 	&micron_spinand_manufacturer,
 	&paragon_spinand_manufacturer,
+	&skyhigh_spinand_manufacturer,
 	&toshiba_spinand_manufacturer,
 	&winbond_spinand_manufacturer,
 	&xtx_spinand_manufacturer,
diff --git a/drivers/mtd/nand/spi/skyhigh.c b/drivers/mtd/nand/spi/skyhigh.c
new file mode 100644
index 000000000000..92e7572094ff
--- /dev/null
+++ b/drivers/mtd/nand/spi/skyhigh.c
@@ -0,0 +1,155 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2022 SkyHigh Memory Limited
+ *
+ * Author: Takahiro Kuwano <takahiro.kuwano@infineon.com>
+ */
+
+#include <linux/device.h>
+#include <linux/kernel.h>
+#include <linux/mtd/spinand.h>
+
+#define SPINAND_MFR_SKYHIGH		0x01
+
+#define SKYHIGH_STATUS_ECC_1TO2_BITFLIPS	(1 << 4)
+#define SKYHIGH_STATUS_ECC_3TO6_BITFLIPS	(2 << 4)
+#define SKYHIGH_STATUS_ECC_UNCOR_ERROR  	(3 << 4)
+
+#define SKYHIGH_CONFIG_PROTECT_EN	BIT(1)
+
+static SPINAND_OP_VARIANTS(read_cache_variants,
+		SPINAND_PAGE_READ_FROM_CACHE_QUADIO_OP(0, 4, NULL, 0),
+		SPINAND_PAGE_READ_FROM_CACHE_X4_OP(0, 1, NULL, 0),
+		SPINAND_PAGE_READ_FROM_CACHE_DUALIO_OP(0, 2, NULL, 0),
+		SPINAND_PAGE_READ_FROM_CACHE_X2_OP(0, 1, NULL, 0),
+		SPINAND_PAGE_READ_FROM_CACHE_OP(true, 0, 1, NULL, 0),
+		SPINAND_PAGE_READ_FROM_CACHE_OP(false, 0, 1, NULL, 0));
+
+static SPINAND_OP_VARIANTS(write_cache_variants,
+		SPINAND_PROG_LOAD_X4(true, 0, NULL, 0),
+		SPINAND_PROG_LOAD(true, 0, NULL, 0));
+
+static SPINAND_OP_VARIANTS(update_cache_variants,
+		SPINAND_PROG_LOAD_X4(false, 0, NULL, 0),
+		SPINAND_PROG_LOAD(false, 0, NULL, 0));
+
+static int skyhigh_spinand_ooblayout_ecc(struct mtd_info *mtd, int section,
+					 struct mtd_oob_region *region)
+{
+	if (section)
+		return -ERANGE;
+
+	/* SkyHigh's ecc parity is stored in the internal hidden area and is not needed for them. */
+	region->length = 0;
+	region->offset = mtd->oobsize;
+
+	return 0;
+}
+
+static int skyhigh_spinand_ooblayout_free(struct mtd_info *mtd, int section,
+					  struct mtd_oob_region *region)
+{
+	if (section)
+		return -ERANGE;
+
+	region->length = mtd->oobsize - 2;
+	region->offset = 2;
+
+	return 0;
+}
+
+static const struct mtd_ooblayout_ops skyhigh_spinand_ooblayout = {
+	.ecc = skyhigh_spinand_ooblayout_ecc,
+	.free = skyhigh_spinand_ooblayout_free,
+};
+
+static int skyhigh_spinand_ecc_get_status(struct spinand_device *spinand,
+				  u8 status)
+{
+	/* SHM
+	 * 00 : No bit-flip
+	 * 01 : 1-2 errors corrected
+	 * 10 : 3-6 errors corrected         
+	 * 11 : uncorrectable
+	 */
+
+	switch (status & STATUS_ECC_MASK) {
+	case STATUS_ECC_NO_BITFLIPS:
+		return 0;
+
+	case SKYHIGH_STATUS_ECC_1TO2_BITFLIPS:
+		return 2;
+
+ 	case SKYHIGH_STATUS_ECC_3TO6_BITFLIPS:
+		return 6; 
+
+ 	case SKYHIGH_STATUS_ECC_UNCOR_ERROR:
+		return -EBADMSG;;
+
+	default:
+		break;
+	}
+
+	return -EINVAL;
+}
+
+static const struct spinand_info skyhigh_spinand_table[] = {
+	SPINAND_INFO("S35ML01G301",
+		     SPINAND_ID(SPINAND_READID_METHOD_OPCODE_DUMMY, 0x15),
+		     NAND_MEMORG(1, 2048, 64, 64, 1024, 20, 1, 1, 1),
+		     NAND_ECCREQ(6, 32),
+		     SPINAND_INFO_OP_VARIANTS(&read_cache_variants,
+					      &write_cache_variants,
+					      &update_cache_variants),
+		     SPINAND_ON_DIE_ECC_MANDATORY,
+		     SPINAND_ECCINFO(&skyhigh_spinand_ooblayout,
+		     		     skyhigh_spinand_ecc_get_status)),
+	SPINAND_INFO("S35ML01G300",
+		     SPINAND_ID(SPINAND_READID_METHOD_OPCODE_DUMMY, 0x14),
+		     NAND_MEMORG(1, 2048, 128, 64, 1024, 20, 1, 1, 1),
+		     NAND_ECCREQ(6, 32),
+		     SPINAND_INFO_OP_VARIANTS(&read_cache_variants,
+					      &write_cache_variants,
+					      &update_cache_variants),
+		     SPINAND_ON_DIE_ECC_MANDATORY,
+		     SPINAND_ECCINFO(&skyhigh_spinand_ooblayout,
+		     		     skyhigh_spinand_ecc_get_status)),
+	SPINAND_INFO("S35ML02G300",
+		     SPINAND_ID(SPINAND_READID_METHOD_OPCODE_DUMMY, 0x25),
+		     NAND_MEMORG(1, 2048, 128, 64, 2048, 40, 2, 1, 1),
+		     NAND_ECCREQ(6, 32),
+		     SPINAND_INFO_OP_VARIANTS(&read_cache_variants,
+					      &write_cache_variants,
+					      &update_cache_variants),
+		     SPINAND_ON_DIE_ECC_MANDATORY,
+		     SPINAND_ECCINFO(&skyhigh_spinand_ooblayout,
+		     		     skyhigh_spinand_ecc_get_status)),
+	SPINAND_INFO("S35ML04G300",
+		     SPINAND_ID(SPINAND_READID_METHOD_OPCODE_DUMMY, 0x35),
+		     NAND_MEMORG(1, 2048, 128, 64, 4096, 80, 2, 1, 1),
+		     NAND_ECCREQ(6, 32),
+		     SPINAND_INFO_OP_VARIANTS(&read_cache_variants,
+					      &write_cache_variants,
+					      &update_cache_variants),
+		     SPINAND_ON_DIE_ECC_MANDATORY,
+		     SPINAND_ECCINFO(&skyhigh_spinand_ooblayout,
+		     		     skyhigh_spinand_ecc_get_status)),
+};
+
+static int skyhigh_spinand_init(struct spinand_device *spinand)
+{
+	return spinand_write_reg_op(spinand, REG_BLOCK_LOCK,
+				    SKYHIGH_CONFIG_PROTECT_EN);
+}
+
+static const struct spinand_manufacturer_ops skyhigh_spinand_manuf_ops = {
+	.init = skyhigh_spinand_init,
+ };
+
+const struct spinand_manufacturer skyhigh_spinand_manufacturer = {
+	.id = SPINAND_MFR_SKYHIGH,
+	.name = "SkyHigh",
+	.chips = skyhigh_spinand_table,
+	.nchips = ARRAY_SIZE(skyhigh_spinand_table),
+	.ops = &skyhigh_spinand_manuf_ops,
+};
diff --git a/include/linux/mtd/spinand.h b/include/linux/mtd/spinand.h
old mode 100644
new mode 100755
index badb4c1ac079..0e135076df24
--- a/include/linux/mtd/spinand.h
+++ b/include/linux/mtd/spinand.h
@@ -268,6 +268,7 @@ extern const struct spinand_manufacturer gigadevice_spinand_manufacturer;
 extern const struct spinand_manufacturer macronix_spinand_manufacturer;
 extern const struct spinand_manufacturer micron_spinand_manufacturer;
 extern const struct spinand_manufacturer paragon_spinand_manufacturer;
+extern const struct spinand_manufacturer skyhigh_spinand_manufacturer;
 extern const struct spinand_manufacturer toshiba_spinand_manufacturer;
 extern const struct spinand_manufacturer winbond_spinand_manufacturer;
 extern const struct spinand_manufacturer xtx_spinand_manufacturer;
@@ -312,6 +313,7 @@ struct spinand_ecc_info {
 
 #define SPINAND_HAS_QE_BIT		BIT(0)
 #define SPINAND_HAS_CR_FEAT_BIT		BIT(1)
+#define SPINAND_ON_DIE_ECC_MANDATORY	BIT(2)	/* SHM */
 
 /**
  * struct spinand_ondie_ecc_conf - private SPI-NAND on-die ECC engine structure
@@ -518,5 +520,6 @@ int spinand_match_and_init(struct spinand_device *spinand,
 
 int spinand_upd_cfg(struct spinand_device *spinand, u8 mask, u8 val);
 int spinand_select_target(struct spinand_device *spinand, unsigned int target);
+int spinand_write_reg_op(struct spinand_device *spinand, u8 reg, u8 val);
 
 #endif /* __LINUX_MTD_SPINAND_H */
-- 
2.34.1


^ permalink raw reply related	[flat|nested] 414+ messages in thread
* Re: [PATCH 2/3] net: microchip_t1s: add support for LAN867x Rev.C1
@ 2023-11-27 13:37 Andrew Lunn
  2023-12-05 10:20 ` Félix Piédallu
  0 siblings, 1 reply; 414+ messages in thread
From: Andrew Lunn @ 2023-11-27 13:37 UTC (permalink / raw)
  To: Ramón N.Rodriguez
  Cc: Heiner Kallweit, Russell King, David S. Miller, Eric Dumazet,
	Jakub Kicinski, Paolo Abeni, netdev, linux-kernel

>  #define PHY_ID_LAN867X_REVB1 0x0007C162
> +#define PHY_ID_LAN867X_REVC1 0x0007C164

So there is a gap in the revisions. Maybe a B2 exists?

> +static int lan867x_revc1_read_fixup_value(struct phy_device *phydev, u16 addr)
> +{
> +	int regval;
> +	/* The AN pretty much just states 'trust us' regarding these magic vals */
> +	const u16 magic_or = 0xE0;
> +	const u16 magic_reg_mask = 0x1F;
> +	const u16 magic_check_mask = 0x10;

Reverse christmass tree please. Longest first, shorted last.

> +	regval = lan865x_revb0_indirect_read(phydev, addr);
> +	if (regval < 0)
> +		return regval;
> +
> +	regval &= magic_reg_mask;
> +
> +	return (regval & magic_check_mask) ? regval | magic_or : regval;
> +}
> +
> +static int lan867x_revc1_config_init(struct phy_device *phydev)
> +{
> +	int err;
> +	int regval;
> +	u16 override0;
> +	u16 override1;
> +	const u16 override_addr0 = 0x4;
> +	const u16 override_addr1 = 0x8;
> +	const u8 index_to_override0 = 2;
> +	const u8 index_to_override1 = 3;

Same here.

> +
> +	err = lan867x_wait_for_reset_complete(phydev);
> +	if (err)
> +		return err;
> +
> +	/* The application note specifies a super convenient process
> +	 * where 2 of the fixup regs needs a write with a value that is
> +	 * a modified result of another reg read.
> +	 * Enjoy the magic show.
> +	 */

I really do hope that by revision D1 they get the firmware sorted out
so none of this undocumented magic is needed.

	Andrew

^ permalink raw reply	[flat|nested] 414+ messages in thread
* (no subject)
@ 2023-11-11  4:21 Andrew Worsley
  2023-11-11  8:22 ` Javier Martinez Canillas
  0 siblings, 1 reply; 414+ messages in thread
From: Andrew Worsley @ 2023-11-11  4:21 UTC (permalink / raw)
  To: Thomas Zimmermann, Javier Martinez Canillas, Maarten Lankhorst,
	Maxime Ripard, David Airlie, Daniel Vetter,
	open list:DRM DRIVER FOR FIRMWARE FRAMEBUFFERS, open list

   This patch fix's the failure of the frame buffer driver on my Asahi kernel
which prevented X11 from starting on my Apple M1 laptop. It seems like a straight
forward failure to follow the procedure described in drivers/video/aperture.c
to remove the ealier driver. This patch is very simple and minimal. Very likely
there may be better ways to fix this and very like there may be other drivers
which have the same problem but I submit this so at least there is
an interim fix for my problem.

    Thanks

    Andrew Worsley


^ permalink raw reply	[flat|nested] 414+ messages in thread
[parent not found: <DB3PR10MB6835AF75D60D9A96465F35C2E8AAA@DB3PR10MB6835.EURPRD10.PROD.OUTLOOK.COM>]
* PIC probing code from e179f6914152 failing
@ 2023-10-18 18:50 Mario Limonciello
  2023-10-18 22:50 ` Thomas Gleixner
  0 siblings, 1 reply; 414+ messages in thread
From: Mario Limonciello @ 2023-10-18 18:50 UTC (permalink / raw)
  To: Hans de Goede, kys, tglx, hpa; +Cc: x86, LKML, Petkov, Borislav

Hi,

Recently an issue was reported to Bugzilla [1] that the Keyboard (IRQ 1) 
and GPIO controller (IRQ 7) weren't working properly on two separate 
Lenovo machines.  The issues are unique to Linux.

In digging through them, they happen because Lenovo didn't set up the 
PIC in the BIOS.
Specifically the PIC probing code introduced by e179f6914152 ("x86, irq, 
pic: Probe for legacy PIC and set legacy_pic appropriately") expects 
that the BIOS sets up the PIC and uses that assertion to let Linux set 
it up.

One of the reporters confirmed that reverting e179f6914152 fixes the 
issue.  Keyboard and GPIO controller both work properly.

I wanted to ask if we can please revert that and come up with a 
different solution for kexec with HyperV.
Can guests instead perhaps detect in early boot code they're running in 
an EFI based hypervisor and explicitly set 'legacy_pic = &null_legacy_pic;'?

[1] https://bugzilla.kernel.org/show_bug.cgi?id=218003

Thanks,

^ permalink raw reply	[flat|nested] 414+ messages in thread
[parent not found: <64b09dbb.630a0220.e80b9.e2ed@mx.google.com>]
* (no subject)
@ 2023-05-11 12:58 Ryan Roberts
  2023-05-11 13:13 ` Ryan Roberts
  0 siblings, 1 reply; 414+ messages in thread
From: Ryan Roberts @ 2023-05-11 12:58 UTC (permalink / raw)
  To: Andrew Morton, Matthew Wilcox (Oracle),
	Kirill A. Shutemov, SeongJae Park
  Cc: Ryan Roberts, linux-kernel, linux-mm, damon

Date: Thu, 11 May 2023 11:38:28 +0100
Subject: [PATCH v1 0/5] Encapsulate PTE contents from non-arch code

Hi All,

This series improves the encapsulation of pte entries by disallowing non-arch
code from directly dereferencing pte_t pointers. Instead code must use a new
helper, `pte_t ptep_deref(pte_t *ptep)`. By default, this helper does a direct
dereference of the pointer, so generated code should be exactly the same. But
it's presence sets us up for arch code being able to override the default to
"virtualize" the ptes without needing to maintain a shadow table.

I intend to take advantage of this for arm64 to enable use of its "contiguous
bit" to coalesce multiple ptes into a single tlb entry, reducing pressure and
improving performance. I have an RFC for the first part of this work at [1]. The
cover letter there also explains the second part, which this series is enabling.

I intend to post an RFC for the contpte changes in due course, but it would be
good to get the ball rolling on this enabler.

There are 2 reasons that I need the encapsulation:

  - Prevent leaking the arch-private PTE_CONT bit to the core code. If the core
    code reads a pte that contains this bit, it could end up calling
    set_pte_at() with the bit set which would confuse the implementation. So we
    can always clear PTE_CONT in ptep_deref() (and ptep_get()) to avoid a leaky
    abstraction.
  - Contiguous ptes have a single access and dirty bit for the contiguous range.
    So we need to "mix-in" those bits when the core is dereferencing a pte that
    lies in the contig range. There is code that dereferences the pte then takes
    different actions based on access/dirty (see e.g. write_protect_page()).

While ptep_get() and ptep_get_lockless() already exist, both of them are
implemented using READ_ONCE() by default. While we could use ptep_get() instead
of the new ptep_deref(), I didn't want to risk performance regression.
Alternatively, all call sites that currently use ptep_get() that need the
lockless behaviour could be upgraded to ptep_get_lockless() and ptep_get() could
be downgraded to a simple dereference. That would be cleanest, but is a much
bigger (and likely error prone) change because all the arch code would need to
be updated for the new definitions of ptep_get().

The series is split up as follows:

patchs 1-2: Fix bugs where code was _setting_ ptes directly, rather than using
            set_pte_at() and friends.
patch 3:    Fix highmem unmapping issue I spotted while doing the work.
patch 4:    Introduce the new ptep_deref() helper with default implementation.
patch 5:    Convert all direct dereferences to use ptep_deref().

[1] https://lore.kernel.org/linux-mm/20230414130303.2345383-1-ryan.roberts@arm.com/

Thanks,
Ryan


Ryan Roberts (5):
  mm: vmalloc must set pte via arch code
  mm: damon must atomically clear young on ptes and pmds
  mm: Fix failure to unmap pte on highmem systems
  mm: Add new ptep_deref() helper to fully encapsulate pte_t
  mm: ptep_deref() conversion

 .../drm/i915/gem/selftests/i915_gem_mman.c    |   8 +-
 drivers/misc/sgi-gru/grufault.c               |   2 +-
 drivers/vfio/vfio_iommu_type1.c               |   7 +-
 drivers/xen/privcmd.c                         |   2 +-
 fs/proc/task_mmu.c                            |  33 +++---
 fs/userfaultfd.c                              |   6 +-
 include/linux/hugetlb.h                       |   2 +-
 include/linux/mm_inline.h                     |   2 +-
 include/linux/pgtable.h                       |  13 ++-
 kernel/events/uprobes.c                       |   2 +-
 mm/damon/ops-common.c                         |  18 ++-
 mm/damon/ops-common.h                         |   4 +-
 mm/damon/paddr.c                              |   6 +-
 mm/damon/vaddr.c                              |  14 ++-
 mm/filemap.c                                  |   2 +-
 mm/gup.c                                      |  21 ++--
 mm/highmem.c                                  |  12 +-
 mm/hmm.c                                      |   2 +-
 mm/huge_memory.c                              |   4 +-
 mm/hugetlb.c                                  |   2 +-
 mm/hugetlb_vmemmap.c                          |   6 +-
 mm/kasan/init.c                               |   9 +-
 mm/kasan/shadow.c                             |  10 +-
 mm/khugepaged.c                               |  24 ++--
 mm/ksm.c                                      |  22 ++--
 mm/madvise.c                                  |   6 +-
 mm/mapping_dirty_helpers.c                    |   4 +-
 mm/memcontrol.c                               |   4 +-
 mm/memory-failure.c                           |   6 +-
 mm/memory.c                                   | 103 +++++++++---------
 mm/mempolicy.c                                |   6 +-
 mm/migrate.c                                  |  14 ++-
 mm/migrate_device.c                           |  14 ++-
 mm/mincore.c                                  |   2 +-
 mm/mlock.c                                    |   6 +-
 mm/mprotect.c                                 |   8 +-
 mm/mremap.c                                   |   2 +-
 mm/page_table_check.c                         |   4 +-
 mm/page_vma_mapped.c                          |  26 +++--
 mm/pgtable-generic.c                          |   2 +-
 mm/rmap.c                                     |  32 +++---
 mm/sparse-vmemmap.c                           |   8 +-
 mm/swap_state.c                               |   4 +-
 mm/swapfile.c                                 |  16 +--
 mm/userfaultfd.c                              |   4 +-
 mm/vmalloc.c                                  |  11 +-
 mm/vmscan.c                                   |  14 ++-
 virt/kvm/kvm_main.c                           |   9 +-
 48 files changed, 302 insertions(+), 236 deletions(-)

--
2.25.1


^ permalink raw reply	[flat|nested] 414+ messages in thread
* Re: [PATCH v2] uas: Add US_FL_NO_REPORT_OPCODES for JMicron JMS583Gen 2
@ 2023-03-12  6:52 Greg Kroah-Hartman
  2023-03-27 13:54 ` Yaroslav Furman
  0 siblings, 1 reply; 414+ messages in thread
From: Greg Kroah-Hartman @ 2023-03-12  6:52 UTC (permalink / raw)
  To: Yaroslav Furman; +Cc: Alan Stern, linux-usb, usb-storage, linux-kernel

On Sat, Mar 11, 2023 at 07:12:26PM +0200, Yaroslav Furman wrote:
> Just like other JMicron JMS5xx enclosures, it chokes on report-opcodes,
> let's avoid them.
> 
> Signed-off-by: Yaroslav Furman <yaro330@gmail.com>
> ---
>  drivers/usb/storage/unusual_uas.h | 7 +++++++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/drivers/usb/storage/unusual_uas.h b/drivers/usb/storage/unusual_uas.h
> index c7b763d6d102..1f8c9b16a0fb 100644
> --- a/drivers/usb/storage/unusual_uas.h
> +++ b/drivers/usb/storage/unusual_uas.h
> @@ -111,6 +111,13 @@ UNUSUAL_DEV(0x152d, 0x0578, 0x0000, 0x9999,
>  		USB_SC_DEVICE, USB_PR_DEVICE, NULL,
>  		US_FL_BROKEN_FUA),
>  
> +/* Reported by: Yaroslav Furman <yaro330@gmail.com> */
> +UNUSUAL_DEV(0x152d, 0x0583, 0x0000, 0x9999,
> +		"JMicron",
> +		"JMS583Gen 2",
> +		USB_SC_DEVICE, USB_PR_DEVICE, NULL,
> +		US_FL_NO_REPORT_OPCODES),
> +
>  /* Reported-by: Thinh Nguyen <thinhn@synopsys.com> */
>  UNUSUAL_DEV(0x154b, 0xf00b, 0x0000, 0x9999,
>  		"PNY",
> -- 
> 2.39.2
> 

Hi,

This is the friendly patch-bot of Greg Kroah-Hartman.  You have sent him
a patch that has triggered this response.  He used to manually respond
to these common problems, but in order to save his sanity (he kept
writing the same thing over and over, yet to different people), I was
created.  Hopefully you will not take offence and will fix the problem
in your patch and resubmit it so that it can be accepted into the Linux
kernel tree.

You are receiving this message because of the following common error(s)
as indicated below:

- This looks like a new version of a previously submitted patch, but you
  did not list below the --- line any changes from the previous version.
  Please read the section entitled "The canonical patch format" in the
  kernel file, Documentation/process/submitting-patches.rst for what
  needs to be done here to properly describe this.

If you wish to discuss this problem further, or you have questions about
how to resolve this issue, please feel free to respond to this email and
Greg will reply once he has dug out from the pending patches received
from other developers.

thanks,

greg k-h's patch email bot

^ permalink raw reply	[flat|nested] 414+ messages in thread
* [PATCH v5 0/5] CXL Poison List Retrieval & Tracing
@ 2023-01-18 20:59 alison.schofield
  2023-01-27  1:59 ` Dan Williams
  0 siblings, 1 reply; 414+ messages in thread
From: alison.schofield @ 2023-01-18 20:59 UTC (permalink / raw)
  To: Dan Williams, Ira Weiny, Vishal Verma, Dave Jiang, Ben Widawsky,
	Steven Rostedt
  Cc: Alison Schofield, linux-cxl, linux-kernel

From: Alison Schofield <alison.schofield@intel.com>

**RESENDING this cover letter previously mis-threaded.

Changes in v5:
- Rebase on cxl/next 
- Use struct_size() to calc mbox cmd payload .min_out
- s/INTERNAL/INJECTED mocked poison record source
- Added Jonathan Reviewed-by tag on Patch 3

Link to v4:
https://lore.kernel.org/linux-cxl/cover.1671135967.git.alison.schofield@intel.com/

Add support for retrieving device poison lists and store the returned
error records as kernel trace events.

The handling of the poison list is guided by the CXL 3.0 Specification
Section 8.2.9.8.4.1. [1] 

Example, triggered by memdev:
$ echo 1 > /sys/bus/cxl/devices/mem3/trigger_poison_list
cxl_poison: memdev=mem3 pcidev=cxl_mem.3 region= region_uuid=00000000-0000-0000-0000-000000000000 dpa=0x0 length=0x40 source=Internal flags= overflow_time=0

Example, triggered by region:
$ echo 1 > /sys/bus/cxl/devices/region5/trigger_poison_list
cxl_poison: memdev=mem0 pcidev=cxl_mem.0 region=region5 region_uuid=bfcb7a29-890e-4a41-8236-fe22221fc75c dpa=0x0 length=0x40 source=Internal flags= overflow_time=0
cxl_poison: memdev=mem1 pcidev=cxl_mem.1 region=region5 region_uuid=bfcb7a29-890e-4a41-8236-fe22221fc75c dpa=0x0 length=0x40 source=Internal flags= overflow_time=0

[1]: https://www.computeexpresslink.org/download-the-specification

Alison Schofield (5):
  cxl/mbox: Add GET_POISON_LIST mailbox command
  cxl/trace: Add TRACE support for CXL media-error records
  cxl/memdev: Add trigger_poison_list sysfs attribute
  cxl/region: Add trigger_poison_list sysfs attribute
  tools/testing/cxl: Mock support for Get Poison List

 Documentation/ABI/testing/sysfs-bus-cxl | 28 +++++++++
 drivers/cxl/core/mbox.c                 | 78 +++++++++++++++++++++++
 drivers/cxl/core/memdev.c               | 45 ++++++++++++++
 drivers/cxl/core/region.c               | 33 ++++++++++
 drivers/cxl/core/trace.h                | 83 +++++++++++++++++++++++++
 drivers/cxl/cxlmem.h                    | 69 +++++++++++++++++++-
 drivers/cxl/pci.c                       |  4 ++
 tools/testing/cxl/test/mem.c            | 42 +++++++++++++
 8 files changed, 381 insertions(+), 1 deletion(-)


base-commit: 589c3357370a596ef7c99c00baca8ac799fce531
-- 
2.37.3


^ permalink raw reply	[flat|nested] 414+ messages in thread
* (no subject)
@ 2022-11-21 11:11 Denis Arefev
  2022-11-21 14:28 ` Jason Yan
  0 siblings, 1 reply; 414+ messages in thread
From: Denis Arefev @ 2022-11-21 11:11 UTC (permalink / raw)
  To: Anil Gurumurthy
  Cc: Sudarsana Kalluru, James E.J. Bottomley, Martin K. Petersen,
	linux-scsi, linux-kernel, trufanov, vfh

Date: Mon, 21 Nov 2022 13:29:03 +0300
Subject: [PATCH] scsi:bfa: Eliminated buffer overflow

Buffer 'cmd->adapter_hwpath' of size 32 accessed at
bfad_bsg.c:101:103 can overflow, since its index 'i'
can have value 32 that is out of range.

Signed-off-by: Denis Arefev <arefev@swemel.ru>
---
 drivers/scsi/bfa/bfad_bsg.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/scsi/bfa/bfad_bsg.c b/drivers/scsi/bfa/bfad_bsg.c
index be8dfbe13e90..78615ffc62ef 100644
--- a/drivers/scsi/bfa/bfad_bsg.c
+++ b/drivers/scsi/bfa/bfad_bsg.c
@@ -98,9 +98,9 @@ bfad_iocmd_ioc_get_info(struct bfad_s *bfad, void *cmd)
 
 	/* set adapter hw path */
 	strcpy(iocmd->adapter_hwpath, bfad->pci_name);
-	for (i = 0; iocmd->adapter_hwpath[i] != ':' && i < BFA_STRING_32; i++)
+	for (i = 0; iocmd->adapter_hwpath[i] != ':' && i < BFA_STRING_32-2; i++)
 		;
-	for (; iocmd->adapter_hwpath[++i] != ':' && i < BFA_STRING_32; )
+	for (; iocmd->adapter_hwpath[++i] != ':' && i < BFA_STRING_32-1; )
 		;
 	iocmd->adapter_hwpath[i] = '\0';
 	iocmd->status = BFA_STATUS_OK;
-- 
2.25.1


^ permalink raw reply related	[flat|nested] 414+ messages in thread
* (no subject)
@ 2022-09-14 13:12 Amjad Ouled-Ameur
  2022-09-14 13:18 ` Amjad Ouled-Ameur
  0 siblings, 1 reply; 414+ messages in thread
From: Amjad Ouled-Ameur @ 2022-09-14 13:12 UTC (permalink / raw)
  To: Rob Herring
  Cc: Amjad Ouled-Ameur, Krzysztof Kozlowski, Matthias Brugger,
	devicetree, linux-arm-kernel, linux-mediatek, linux-kernel

Subject: [PATCH] arm64: dts: mediatek: mt8183: remove thermal zones without
 trips.

Thermal zones without trip point are not registered by thermal core.

tzts1 ~ tzts6 zones of mt8183 were intially introduced for test-purpose
only but are not supposed to remain on DT.

Remove the zones above and keep only cpu_thermal.

Signed-off-by: Amjad Ouled-Ameur <aouledameur@baylibre.com>
---
 arch/arm64/boot/dts/mediatek/mt8183.dtsi | 57 ------------------------
 1 file changed, 57 deletions(-)

diff --git a/arch/arm64/boot/dts/mediatek/mt8183.dtsi b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
index 9d32871973a2..f65fae8939de 100644
--- a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
@@ -1182,63 +1182,6 @@ THERMAL_NO_LIMIT
 					};
 				};
 			};
-
-			/* The tzts1 ~ tzts6 don't need to polling */
-			/* The tzts1 ~ tzts6 don't need to thermal throttle */
-
-			tzts1: tzts1 {
-				polling-delay-passive = <0>;
-				polling-delay = <0>;
-				thermal-sensors = <&thermal 1>;
-				sustainable-power = <5000>;
-				trips {};
-				cooling-maps {};
-			};
-
-			tzts2: tzts2 {
-				polling-delay-passive = <0>;
-				polling-delay = <0>;
-				thermal-sensors = <&thermal 2>;
-				sustainable-power = <5000>;
-				trips {};
-				cooling-maps {};
-			};
-
-			tzts3: tzts3 {
-				polling-delay-passive = <0>;
-				polling-delay = <0>;
-				thermal-sensors = <&thermal 3>;
-				sustainable-power = <5000>;
-				trips {};
-				cooling-maps {};
-			};
-
-			tzts4: tzts4 {
-				polling-delay-passive = <0>;
-				polling-delay = <0>;
-				thermal-sensors = <&thermal 4>;
-				sustainable-power = <5000>;
-				trips {};
-				cooling-maps {};
-			};
-
-			tzts5: tzts5 {
-				polling-delay-passive = <0>;
-				polling-delay = <0>;
-				thermal-sensors = <&thermal 5>;
-				sustainable-power = <5000>;
-				trips {};
-				cooling-maps {};
-			};
-
-			tztsABB: tztsABB {
-				polling-delay-passive = <0>;
-				polling-delay = <0>;
-				thermal-sensors = <&thermal 6>;
-				sustainable-power = <5000>;
-				trips {};
-				cooling-maps {};
-			};
 		};
 
 		pwm0: pwm@1100e000 {
-- 
2.37.3


^ permalink raw reply related	[flat|nested] 414+ messages in thread
* [PATCH bpf-next 1/2] cpuidle/rcu: Making arch_cpu_idle and rcu_idle_exit noinstr
@ 2022-05-15 20:36 Jiri Olsa
  2023-05-20  9:47 ` Ze Gao
  0 siblings, 1 reply; 414+ messages in thread
From: Jiri Olsa @ 2022-05-15 20:36 UTC (permalink / raw)
  To: Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko,
	Masami Hiramatsu, Paul E. McKenney
  Cc: netdev, bpf, lkml, Martin KaFai Lau, Song Liu, Yonghong Song,
	John Fastabend, KP Singh, Steven Rostedt

Making arch_cpu_idle and rcu_idle_exit noinstr. Both functions run
in rcu 'not watching' context and if there's tracer attached to
them, which uses rcu (e.g. kprobe multi interface) it will hit RCU
warning like:

  [    3.017540] WARNING: suspicious RCU usage
  ...
  [    3.018363]  kprobe_multi_link_handler+0x68/0x1c0
  [    3.018364]  ? kprobe_multi_link_handler+0x3e/0x1c0
  [    3.018366]  ? arch_cpu_idle_dead+0x10/0x10
  [    3.018367]  ? arch_cpu_idle_dead+0x10/0x10
  [    3.018371]  fprobe_handler.part.0+0xab/0x150
  [    3.018374]  0xffffffffa00080c8
  [    3.018393]  ? arch_cpu_idle+0x5/0x10
  [    3.018398]  arch_cpu_idle+0x5/0x10
  [    3.018399]  default_idle_call+0x59/0x90
  [    3.018401]  do_idle+0x1c3/0x1d0

The call path is following:

default_idle_call
  rcu_idle_enter
  arch_cpu_idle
  rcu_idle_exit

The arch_cpu_idle and rcu_idle_exit are the only ones from above
path that are traceble and cause this problem on my setup.

Signed-off-by: Jiri Olsa <jolsa@kernel.org>
---
 arch/x86/kernel/process.c | 2 +-
 kernel/rcu/tree.c         | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c
index b370767f5b19..1345cb0124a6 100644
--- a/arch/x86/kernel/process.c
+++ b/arch/x86/kernel/process.c
@@ -720,7 +720,7 @@ void arch_cpu_idle_dead(void)
 /*
  * Called from the generic idle code.
  */
-void arch_cpu_idle(void)
+void noinstr arch_cpu_idle(void)
 {
 	x86_idle();
 }
diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
index a4b8189455d5..20d529722f51 100644
--- a/kernel/rcu/tree.c
+++ b/kernel/rcu/tree.c
@@ -896,7 +896,7 @@ static void noinstr rcu_eqs_exit(bool user)
  * If you add or remove a call to rcu_idle_exit(), be sure to test with
  * CONFIG_RCU_EQS_DEBUG=y.
  */
-void rcu_idle_exit(void)
+void noinstr rcu_idle_exit(void)
 {
 	unsigned long flags;
 
-- 
2.35.3


^ permalink raw reply related	[flat|nested] 414+ messages in thread
[parent not found: <CANiq72k+5Rdj7i3Df2dcE6_OPYPXK3z5EWLKnY56sSMz4G3OvA@mail.gmail.com>]
* (no subject)
@ 2022-04-21 16:41 Yury Norov
  2022-04-21 23:04 ` John Hubbard
  0 siblings, 1 reply; 414+ messages in thread
From: Yury Norov @ 2022-04-21 16:41 UTC (permalink / raw)
  To: Andrew Morton, Minchan Kim, John Hubbard, linux-mm, linux-kernel
  Cc: Yury Norov

Subject: [PATCH] mm/gup: fix comments to pin_user_pages_*()

pin_user_pages API forces FOLL_PIN in gup_flags, which means that the
API requires struct page **pages to be provided (not NULL). However,
the comment to pin_user_pages() says:

    * @pages:      array that receives pointers to the pages pinned.
    *              Should be at least nr_pages long. Or NULL, if caller
    *              only intends to ensure the pages are faulted in.

This patch fixes comments along the pin_user_pages code, and also adds
WARN_ON(!pages), so that API users will have better understanding
on how to use it.

It has been independently spotted by Minchan Kim and confirmed with
John Hubbard:

https://lore.kernel.org/all/YgWA0ghrrzHONehH@google.com/

Signed-off-by: Yury Norov (NVIDIA) <yury.norov@gmail.com>
---
 mm/gup.c | 26 ++++++++++++++++++++++----
 1 file changed, 22 insertions(+), 4 deletions(-)

diff --git a/mm/gup.c b/mm/gup.c
index f598a037eb04..559626457585 100644
--- a/mm/gup.c
+++ b/mm/gup.c
@@ -2871,6 +2871,10 @@ int pin_user_pages_fast(unsigned long start, int nr_pages,
 	if (WARN_ON_ONCE(gup_flags & FOLL_GET))
 		return -EINVAL;
 
+	/* FOLL_PIN requires pages != NULL */
+	if (WARN_ON_ONCE(!pages))
+		return -EINVAL;
+
 	gup_flags |= FOLL_PIN;
 	return internal_get_user_pages_fast(start, nr_pages, gup_flags, pages);
 }
@@ -2893,6 +2897,10 @@ int pin_user_pages_fast_only(unsigned long start, int nr_pages,
 	 */
 	if (WARN_ON_ONCE(gup_flags & FOLL_GET))
 		return 0;
+
+	/* FOLL_PIN requires pages != NULL */
+	if (WARN_ON_ONCE(!pages))
+		return 0;
 	/*
 	 * FOLL_FAST_ONLY is required in order to match the API description of
 	 * this routine: no fall back to regular ("slow") GUP.
@@ -2920,8 +2928,7 @@ EXPORT_SYMBOL_GPL(pin_user_pages_fast_only);
  * @nr_pages:	number of pages from start to pin
  * @gup_flags:	flags modifying lookup behaviour
  * @pages:	array that receives pointers to the pages pinned.
- *		Should be at least nr_pages long. Or NULL, if caller
- *		only intends to ensure the pages are faulted in.
+ *		Should be at least nr_pages long.
  * @vmas:	array of pointers to vmas corresponding to each page.
  *		Or NULL if the caller does not require them.
  * @locked:	pointer to lock flag indicating whether lock is held and
@@ -2944,6 +2951,10 @@ long pin_user_pages_remote(struct mm_struct *mm,
 	if (WARN_ON_ONCE(gup_flags & FOLL_GET))
 		return -EINVAL;
 
+	/* FOLL_PIN requires pages != NULL */
+	if (WARN_ON_ONCE(!pages))
+		return -EINVAL;
+
 	gup_flags |= FOLL_PIN;
 	return __get_user_pages_remote(mm, start, nr_pages, gup_flags,
 				       pages, vmas, locked);
@@ -2957,8 +2968,7 @@ EXPORT_SYMBOL(pin_user_pages_remote);
  * @nr_pages:	number of pages from start to pin
  * @gup_flags:	flags modifying lookup behaviour
  * @pages:	array that receives pointers to the pages pinned.
- *		Should be at least nr_pages long. Or NULL, if caller
- *		only intends to ensure the pages are faulted in.
+ *		Should be at least nr_pages long.
  * @vmas:	array of pointers to vmas corresponding to each page.
  *		Or NULL if the caller does not require them.
  *
@@ -2976,6 +2986,10 @@ long pin_user_pages(unsigned long start, unsigned long nr_pages,
 	if (WARN_ON_ONCE(gup_flags & FOLL_GET))
 		return -EINVAL;
 
+	/* FOLL_PIN requires pages != NULL */
+	if (WARN_ON_ONCE(!pages))
+		return -EINVAL;
+
 	gup_flags |= FOLL_PIN;
 	return __gup_longterm_locked(current->mm, start, nr_pages,
 				     pages, vmas, gup_flags);
@@ -2994,6 +3008,10 @@ long pin_user_pages_unlocked(unsigned long start, unsigned long nr_pages,
 	if (WARN_ON_ONCE(gup_flags & FOLL_GET))
 		return -EINVAL;
 
+	/* FOLL_PIN requires pages != NULL */
+	if (WARN_ON_ONCE(!pages))
+		return -EINVAL;
+
 	gup_flags |= FOLL_PIN;
 	return get_user_pages_unlocked(start, nr_pages, pages, gup_flags);
 }
-- 
2.32.0


^ permalink raw reply related	[flat|nested] 414+ messages in thread
* (no subject)
@ 2022-03-25  6:30 Michael S. Tsirkin
  2022-03-25  7:52 ` Jason Wang
  0 siblings, 1 reply; 414+ messages in thread
From: Michael S. Tsirkin @ 2022-03-25  6:30 UTC (permalink / raw)
  To: Jason Wang
  Cc: virtualization, linux-kernel, maz, tglx, peterz, sgarzare, keirf,
	Paul E. McKenney

Bcc: 
Subject: Re: [PATCH 3/3] virtio: harden vring IRQ
Message-ID: <20220325021422-mutt-send-email-mst@kernel.org>
Reply-To: 
In-Reply-To: <f7046303-7d7d-e39f-3c71-3688126cc812@redhat.com>

On Fri, Mar 25, 2022 at 11:04:08AM +0800, Jason Wang wrote:
> 
> 在 2022/3/24 下午7:03, Michael S. Tsirkin 写道:
> > On Thu, Mar 24, 2022 at 04:40:04PM +0800, Jason Wang wrote:
> > > This is a rework on the previous IRQ hardening that is done for
> > > virtio-pci where several drawbacks were found and were reverted:
> > > 
> > > 1) try to use IRQF_NO_AUTOEN which is not friendly to affinity managed IRQ
> > >     that is used by some device such as virtio-blk
> > > 2) done only for PCI transport
> > > 
> > > In this patch, we tries to borrow the idea from the INTX IRQ hardening
> > > in the reverted commit 080cd7c3ac87 ("virtio-pci: harden INTX interrupts")
> > > by introducing a global irq_soft_enabled variable for each
> > > virtio_device. Then we can to toggle it during
> > > virtio_reset_device()/virtio_device_ready(). A synchornize_rcu() is
> > > used in virtio_reset_device() to synchronize with the IRQ handlers. In
> > > the future, we may provide config_ops for the transport that doesn't
> > > use IRQ. With this, vring_interrupt() can return check and early if
> > > irq_soft_enabled is false. This lead to smp_load_acquire() to be used
> > > but the cost should be acceptable.
> > Maybe it should be but is it? Can't we use synchronize_irq instead?
> 
> 
> Even if we allow the transport driver to synchornize through
> synchronize_irq() we still need a check in the vring_interrupt().
> 
> We do something like the following previously:
> 
>         if (!READ_ONCE(vp_dev->intx_soft_enabled))
>                 return IRQ_NONE;
> 
> But it looks like a bug since speculative read can be done before the check
> where the interrupt handler can't see the uncommitted setup which is done by
> the driver.

I don't think so - if you sync after setting the value then
you are guaranteed that any handler running afterwards
will see the new value.

Although I couldn't find anything about this in memory-barriers.txt
which surprises me.

CC Paul to help make sure I'm right.


> 
> > 
> > > To avoid breaking legacy device which can send IRQ before DRIVER_OK, a
> > > module parameter is introduced to enable the hardening so function
> > > hardening is disabled by default.
> > Which devices are these? How come they send an interrupt before there
> > are any buffers in any queues?
> 
> 
> I copied this from the commit log for 22b7050a024d7
> 
> "
> 
>     This change will also benefit old hypervisors (before 2009)
>     that send interrupts without checking DRIVER_OK: previously,
>     the callback could race with driver-specific initialization.
> "
> 
> If this is only for config interrupt, I can remove the above log.


This is only for config interrupt.

> 
> > 
> > > Note that the hardening is only done for vring interrupt since the
> > > config interrupt hardening is already done in commit 22b7050a024d7
> > > ("virtio: defer config changed notifications"). But the method that is
> > > used by config interrupt can't be reused by the vring interrupt
> > > handler because it uses spinlock to do the synchronization which is
> > > expensive.
> > > 
> > > Signed-off-by: Jason Wang <jasowang@redhat.com>
> > 
> > > ---
> > >   drivers/virtio/virtio.c       | 19 +++++++++++++++++++
> > >   drivers/virtio/virtio_ring.c  |  9 ++++++++-
> > >   include/linux/virtio.h        |  4 ++++
> > >   include/linux/virtio_config.h | 25 +++++++++++++++++++++++++
> > >   4 files changed, 56 insertions(+), 1 deletion(-)
> > > 
> > > diff --git a/drivers/virtio/virtio.c b/drivers/virtio/virtio.c
> > > index 8dde44ea044a..85e331efa9cc 100644
> > > --- a/drivers/virtio/virtio.c
> > > +++ b/drivers/virtio/virtio.c
> > > @@ -7,6 +7,12 @@
> > >   #include <linux/of.h>
> > >   #include <uapi/linux/virtio_ids.h>
> > > +static bool irq_hardening = false;
> > > +
> > > +module_param(irq_hardening, bool, 0444);
> > > +MODULE_PARM_DESC(irq_hardening,
> > > +		 "Disalbe IRQ software processing when it is not expected");
> > > +
> > >   /* Unique numbering for virtio devices. */
> > >   static DEFINE_IDA(virtio_index_ida);
> > > @@ -220,6 +226,15 @@ static int virtio_features_ok(struct virtio_device *dev)
> > >    * */
> > >   void virtio_reset_device(struct virtio_device *dev)
> > >   {
> > > +	/*
> > > +	 * The below synchronize_rcu() guarantees that any
> > > +	 * interrupt for this line arriving after
> > > +	 * synchronize_rcu() has completed is guaranteed to see
> > > +	 * irq_soft_enabled == false.
> > News to me I did not know synchronize_rcu has anything to do
> > with interrupts. Did not you intend to use synchronize_irq?
> > I am not even 100% sure synchronize_rcu is by design a memory barrier
> > though it's most likely is ...
> 
> 
> According to the comment above tree RCU version of synchronize_rcu():
> 
> """
> 
>  * RCU read-side critical sections are delimited by rcu_read_lock()
>  * and rcu_read_unlock(), and may be nested.  In addition, but only in
>  * v5.0 and later, regions of code across which interrupts, preemption,
>  * or softirqs have been disabled also serve as RCU read-side critical
>  * sections.  This includes hardware interrupt handlers, softirq handlers,
>  * and NMI handlers.
> """
> 
> So interrupt handlers are treated as read-side critical sections.
> 
> And it has the comment for explain the barrier:
> 
> """
> 
>  * Note that this guarantee implies further memory-ordering guarantees.
>  * On systems with more than one CPU, when synchronize_rcu() returns,
>  * each CPU is guaranteed to have executed a full memory barrier since
>  * the end of its last RCU read-side critical section whose beginning
>  * preceded the call to synchronize_rcu().  In addition, each CPU having
> """
> 
> So on SMP it provides a full barrier. And for UP/tiny RCU we don't need the
> barrier, if the interrupt come after WRITE_ONCE() it will see the
> irq_soft_enabled as false.
> 

You are right. So then
1. I do not think we need load_acquire - why is it needed? Just
   READ_ONCE should do.
2. isn't synchronize_irq also doing the same thing?


> > 
> > > +	 */
> > > +	WRITE_ONCE(dev->irq_soft_enabled, false);
> > > +	synchronize_rcu();
> > > +
> > >   	dev->config->reset(dev);
> > >   }
> > >   EXPORT_SYMBOL_GPL(virtio_reset_device);
> > Please add comment explaining where it will be enabled.
> > Also, we *really* don't need to synch if it was already disabled,
> > let's not add useless overhead to the boot sequence.
> 
> 
> Ok.
> 
> 
> > 
> > 
> > > @@ -427,6 +442,10 @@ int register_virtio_device(struct virtio_device *dev)
> > >   	spin_lock_init(&dev->config_lock);
> > >   	dev->config_enabled = false;
> > >   	dev->config_change_pending = false;
> > > +	dev->irq_soft_check = irq_hardening;
> > > +
> > > +	if (dev->irq_soft_check)
> > > +		dev_info(&dev->dev, "IRQ hardening is enabled\n");
> > >   	/* We always start by resetting the device, in case a previous
> > >   	 * driver messed it up.  This also tests that code path a little. */
> > one of the points of hardening is it's also helpful for buggy
> > devices. this flag defeats the purpose.
> 
> 
> Do you mean:
> 
> 1) we need something like config_enable? This seems not easy to be
> implemented without obvious overhead, mainly the synchronize with the
> interrupt handlers

But synchronize is only on tear-down path. That is not critical for any
users at the moment, even less than probe.

> 2) enable this by default, so I don't object, but this may have some risk
> for old hypervisors


The risk if there's a driver adding buffers without setting DRIVER_OK.
So with this approach, how about we rename the flag "driver_ok"?
And then add_buf can actually test it and BUG_ON if not there  (at least
in the debug build).

And going down from there, how about we cache status in the
device? Then we don't need to keep re-reading it every time,
speeding boot up a tiny bit.

> 
> > 
> > > diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c
> > > index 962f1477b1fa..0170f8c784d8 100644
> > > --- a/drivers/virtio/virtio_ring.c
> > > +++ b/drivers/virtio/virtio_ring.c
> > > @@ -2144,10 +2144,17 @@ static inline bool more_used(const struct vring_virtqueue *vq)
> > >   	return vq->packed_ring ? more_used_packed(vq) : more_used_split(vq);
> > >   }
> > > -irqreturn_t vring_interrupt(int irq, void *_vq)
> > > +irqreturn_t vring_interrupt(int irq, void *v)
> > >   {
> > > +	struct virtqueue *_vq = v;
> > > +	struct virtio_device *vdev = _vq->vdev;
> > >   	struct vring_virtqueue *vq = to_vvq(_vq);
> > > +	if (!virtio_irq_soft_enabled(vdev)) {
> > > +		dev_warn_once(&vdev->dev, "virtio vring IRQ raised before DRIVER_OK");
> > > +		return IRQ_NONE;
> > > +	}
> > > +
> > >   	if (!more_used(vq)) {
> > >   		pr_debug("virtqueue interrupt with no work for %p\n", vq);
> > >   		return IRQ_NONE;
> > > diff --git a/include/linux/virtio.h b/include/linux/virtio.h
> > > index 5464f398912a..957d6ad604ac 100644
> > > --- a/include/linux/virtio.h
> > > +++ b/include/linux/virtio.h
> > > @@ -95,6 +95,8 @@ dma_addr_t virtqueue_get_used_addr(struct virtqueue *vq);
> > >    * @failed: saved value for VIRTIO_CONFIG_S_FAILED bit (for restore)
> > >    * @config_enabled: configuration change reporting enabled
> > >    * @config_change_pending: configuration change reported while disabled
> > > + * @irq_soft_check: whether or not to check @irq_soft_enabled
> > > + * @irq_soft_enabled: callbacks enabled
> > >    * @config_lock: protects configuration change reporting
> > >    * @dev: underlying device.
> > >    * @id: the device type identification (used to match it with a driver).
> > > @@ -109,6 +111,8 @@ struct virtio_device {
> > >   	bool failed;
> > >   	bool config_enabled;
> > >   	bool config_change_pending;
> > > +	bool irq_soft_check;
> > > +	bool irq_soft_enabled;
> > >   	spinlock_t config_lock;
> > >   	spinlock_t vqs_list_lock; /* Protects VQs list access */
> > >   	struct device dev;
> > > diff --git a/include/linux/virtio_config.h b/include/linux/virtio_config.h
> > > index dafdc7f48c01..9c1b61f2e525 100644
> > > --- a/include/linux/virtio_config.h
> > > +++ b/include/linux/virtio_config.h
> > > @@ -174,6 +174,24 @@ static inline bool virtio_has_feature(const struct virtio_device *vdev,
> > >   	return __virtio_test_bit(vdev, fbit);
> > >   }
> > > +/*
> > > + * virtio_irq_soft_enabled: whether we can execute callbacks
> > > + * @vdev: the device
> > > + */
> > > +static inline bool virtio_irq_soft_enabled(const struct virtio_device *vdev)
> > > +{
> > > +	if (!vdev->irq_soft_check)
> > > +		return true;
> > > +
> > > +	/*
> > > +	 * Read irq_soft_enabled before reading other device specific
> > > +	 * data. Paried with smp_store_relase() in
> > paired
> 
> 
> Will fix.
> 
> Thanks
> 
> 
> > 
> > > +	 * virtio_device_ready() and WRITE_ONCE()/synchronize_rcu() in
> > > +	 * virtio_reset_device().
> > > +	 */
> > > +	return smp_load_acquire(&vdev->irq_soft_enabled);
> > > +}
> > > +
> > >   /**
> > >    * virtio_has_dma_quirk - determine whether this device has the DMA quirk
> > >    * @vdev: the device
> > > @@ -236,6 +254,13 @@ void virtio_device_ready(struct virtio_device *dev)
> > >   	if (dev->config->enable_cbs)
> > >                     dev->config->enable_cbs(dev);
> > > +	/*
> > > +	 * Commit the driver setup before enabling the virtqueue
> > > +	 * callbacks. Paried with smp_load_acuqire() in
> > > +	 * virtio_irq_soft_enabled()
> > > +	 */
> > > +	smp_store_release(&dev->irq_soft_enabled, true);
> > > +
> > >   	BUG_ON(status & VIRTIO_CONFIG_S_DRIVER_OK);
> > >   	dev->config->set_status(dev, status | VIRTIO_CONFIG_S_DRIVER_OK);
> > >   }
> > > -- 
> > > 2.25.1


^ permalink raw reply	[flat|nested] 414+ messages in thread
* (no subject)
@ 2022-01-20 15:28 Myrtle Shah
  2022-01-20 15:37 ` Vitaly Wool
  0 siblings, 1 reply; 414+ messages in thread
From: Myrtle Shah @ 2022-01-20 15:28 UTC (permalink / raw)
  To: linux-riscv, paul.walmsley, palmer; +Cc: linux-kernel

These are some initial patches to bugs I found attempting to
get a XIP kernel working on hardware:
 - 32-bit VexRiscv processor
 - kernel in SPI flash, at 0x00200000
 - 16MB of RAM at 0x10000000
 - MMU enabled
 
I still have some more debugging to do, but these at least
get the kernel as far as initialising the MMU, and I would
appreciate feedback if anyone else is working on RISC-V XIP.



^ permalink raw reply	[flat|nested] 414+ messages in thread
[parent not found: <20211126221034.21331-1-lukasz.bartosik@semihalf.com--annotate>]
* [PATCH v5 00/11] Add support for X86/ACPI camera sensor/PMIC setup with clk and regulator platform data
@ 2021-11-02  9:48 Hans de Goede
  2021-11-02  9:49 ` [PATCH v5 05/11] clk: Introduce clk-tps68470 driver Hans de Goede
  0 siblings, 1 reply; 414+ messages in thread
From: Hans de Goede @ 2021-11-02  9:48 UTC (permalink / raw)
  To: Rafael J . Wysocki, Mark Gross, Andy Shevchenko, Wolfram Sang,
	Mika Westerberg, Daniel Scally, Laurent Pinchart,
	Mauro Carvalho Chehab, Liam Girdwood, Mark Brown,
	Michael Turquette, Stephen Boyd
  Cc: Hans de Goede, Len Brown, linux-acpi, platform-driver-x86,
	linux-kernel, linux-i2c, Sakari Ailus, Kate Hsuan, linux-media,
	linux-clk

Here is v5 of my patch-set adding support for camera sensor connected to a
TPS68470 PMIC on x86/ACPI devices.

Changes in v5:
- Update regulator_init_data in patch 10/11 to include the VCM regulator
- Address various small review remarks from Andy
- Make a couple of functions / vars static in the clk + regulator drivers
  Reported-by: kernel test robot <lkp@intel.com>

Changes in v4:
[PATCH 01/11] ACPI: delay enumeration of devices with a _DEP
              pointing to an INT3472 device:
- Move the acpi_dev_ready_for_enumeration() check to acpi_bus_attach()
  (replacing the acpi_device_is_present() check there)

[PATCH 04/11] regulator: Introduce tps68470-regulator driver:
- Make the top comment block use c++ style comments
- Drop the bogus builtin regulator_init_data
- Make the driver enable the PMIC clk when enabling the Core buck
  regulator, this switching regulator needs the PLL to be on
- Kconfig: add || COMPILE_TEST, fix help text

[PATCH 05/11] clk: Introduce clk-tps68470 driver
- Kconfig: select REGMAP_I2C, add || COMPILE_TEST, fix help text
- tps68470_clk_prepare(): Wait for the PLL to lock before returning
- tps68470_clk_unprepare(): Remove unnecesary clearing of divider regs
- tps68470_clk_probe(): Use devm_clk_hw_register()
- Misc. small cleanups

I'm quite happy with how this works now, so from my pov this is the final
version of the device-instantiation deferral code / approach.

###

The clk and regulator frameworks expect clk/regulator consumer-devices
to have info about the consumed clks/regulators described in the device's
fw_node, but on ACPI this info is missing.

This series worksaround this by providing platform_data with the info to
the TPS68470 clk/regulator MFD cells.

Patches 1 - 2 deal with a probe-ordering problem this introduces,
since the lookups are only registered when the provider-driver binds,
trying to get these clks/regulators before then results in a -ENOENT
error for clks and a dummy regulator for regulators. See the patches
for more details.

Patch 3 adds a header file which adds tps68470_clk_platform_data and
tps68470_regulator_platform_data structs. The futher patches depend on
this new header file.

Patch 4 + 5 add the TPS68470 clk and regulator drivers

Patches 6 - 11 Modify the INT3472 driver which instantiates the MFD cells to
provide the necessary platform-data.

Assuming this series is acceptable to everyone, we need to talk about how
to merge this.

Patch 2 has already been acked by Wolfram for merging by Rafael, so patch
1 + 2 can be merged into linux-pm, independent of the rest of the series
(there are some runtime deps on other changes for everything to work,
but the camera-sensors impacted by this are not fully supported yet in
the mainline kernel anyways).

For "[PATCH 03/13] platform_data: Add linux/platform_data/tps68470.h file",
which all further patches depend on I plan to provide an immutable branch
myself (once it has been reviewed), which the clk / regulator maintainers
can then merge before merging the clk / regulator driver which depends on
this.

And I will merge that IM-branch + patches 6-11 into the pdx86 tree myself.

Regards,

Hans


Daniel Scally (1):
  platform/x86: int3472: Enable I2c daisy chain

Hans de Goede (10):
  ACPI: delay enumeration of devices with a _DEP pointing to an INT3472
    device
  i2c: acpi: Use acpi_dev_ready_for_enumeration() helper
  platform_data: Add linux/platform_data/tps68470.h file
  regulator: Introduce tps68470-regulator driver
  clk: Introduce clk-tps68470 driver
  platform/x86: int3472: Split into 2 drivers
  platform/x86: int3472: Add get_sensor_adev_and_name() helper
  platform/x86: int3472: Pass tps68470_clk_platform_data to the
    tps68470-regulator MFD-cell
  platform/x86: int3472: Pass tps68470_regulator_platform_data to the
    tps68470-regulator MFD-cell
  platform/x86: int3472: Deal with probe ordering issues

 drivers/acpi/scan.c                           |  37 ++-
 drivers/clk/Kconfig                           |   8 +
 drivers/clk/Makefile                          |   1 +
 drivers/clk/clk-tps68470.c                    | 257 ++++++++++++++++++
 drivers/i2c/i2c-core-acpi.c                   |   5 +-
 drivers/platform/x86/intel/int3472/Makefile   |   9 +-
 ...lk_and_regulator.c => clk_and_regulator.c} |   2 +-
 drivers/platform/x86/intel/int3472/common.c   |  82 ++++++
 .../{intel_skl_int3472_common.h => common.h}  |   6 +-
 ...ntel_skl_int3472_discrete.c => discrete.c} |  51 ++--
 .../intel/int3472/intel_skl_int3472_common.c  | 106 --------
 ...ntel_skl_int3472_tps68470.c => tps68470.c} |  99 ++++++-
 drivers/platform/x86/intel/int3472/tps68470.h |  25 ++
 .../x86/intel/int3472/tps68470_board_data.c   | 134 +++++++++
 drivers/regulator/Kconfig                     |   9 +
 drivers/regulator/Makefile                    |   1 +
 drivers/regulator/tps68470-regulator.c        | 212 +++++++++++++++
 include/acpi/acpi_bus.h                       |   5 +-
 include/linux/mfd/tps68470.h                  |  11 +
 include/linux/platform_data/tps68470.h        |  35 +++
 20 files changed, 944 insertions(+), 151 deletions(-)
 create mode 100644 drivers/clk/clk-tps68470.c
 rename drivers/platform/x86/intel/int3472/{intel_skl_int3472_clk_and_regulator.c => clk_and_regulator.c} (99%)
 create mode 100644 drivers/platform/x86/intel/int3472/common.c
 rename drivers/platform/x86/intel/int3472/{intel_skl_int3472_common.h => common.h} (94%)
 rename drivers/platform/x86/intel/int3472/{intel_skl_int3472_discrete.c => discrete.c} (91%)
 delete mode 100644 drivers/platform/x86/intel/int3472/intel_skl_int3472_common.c
 rename drivers/platform/x86/intel/int3472/{intel_skl_int3472_tps68470.c => tps68470.c} (54%)
 create mode 100644 drivers/platform/x86/intel/int3472/tps68470.h
 create mode 100644 drivers/platform/x86/intel/int3472/tps68470_board_data.c
 create mode 100644 drivers/regulator/tps68470-regulator.c
 create mode 100644 include/linux/platform_data/tps68470.h

-- 
2.31.1


^ permalink raw reply	[flat|nested] 414+ messages in thread
[parent not found: <CAP7CzPcLhtXDyLudfmR2pWR5fzSQ_jhJSoRheH=cytoDnb_ujg@mail.gmail.com>]
* (no subject)
@ 2021-08-12  9:21 Valdis Klētnieks
  2021-08-12  9:42 ` SeongJae Park
  0 siblings, 1 reply; 414+ messages in thread
From: Valdis Klētnieks @ 2021-08-12  9:21 UTC (permalink / raw)
  To: SeongJae Park, Andrew Morton; +Cc: linux-mm, linux-kernel

[-- Attachment #1: Type: text/plain, Size: 832 bytes --]

In this commit:

commit fedc37448fb1be5d03e420ca7791d4286893d5ec
Author: SeongJae Park <sjpark@amazon.de>
Date:   Tue Aug 10 16:55:51 2021 +1000

    mm/idle_page_tracking: make PG_idle reusable

diff --git a/mm/Kconfig b/mm/Kconfig
index 504336de9a1e..d0b85dc12429 100644
--- a/mm/Kconfig
+++ b/mm/Kconfig
@@ -739,10 +739,18 @@ config DEFERRED_STRUCT_PAGE_INIT
          lifetime of the system until these kthreads finish the
          initialisation.

+config PAGE_IDLE_FLAG
+       bool "Add PG_idle and PG_young flags"
+       help
+         This feature adds PG_idle and PG_young flags in 'struct page'.  PTE
+         Accessed bit writers can set the state of the bit in the flags to let
+         other PTE Accessed bit readers don't disturbed.

This needs to be converted to proper, or at least comprehensible, English....


[-- Attachment #2: Type: application/pgp-signature, Size: 494 bytes --]

^ permalink raw reply related	[flat|nested] 414+ messages in thread
* [PATCH v9] iomap: Support file tail packing
@ 2021-07-27  2:59 Gao Xiang
  2021-07-27 15:10 ` Darrick J. Wong
  0 siblings, 1 reply; 414+ messages in thread
From: Gao Xiang @ 2021-07-27  2:59 UTC (permalink / raw)
  To: linux-erofs, linux-fsdevel
  Cc: LKML, Huang Jianan, Joseph Qi, Gao Xiang, Darrick J . Wong,
	Christoph Hellwig, Matthew Wilcox, Andreas Gruenbacher

The existing inline data support only works for cases where the entire
file is stored as inline data.  For larger files, EROFS stores the
initial blocks separately and then can pack a small tail adjacent to the
inode.  Generalise inline data to allow for tail packing.  Tails may not
cross a page boundary in memory.

We currently have no filesystems that support tail packing and writing,
so that case is currently disabled (see iomap_write_begin_inline).

Cc: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Matthew Wilcox (Oracle) <willy@infradead.org>
Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com>
Signed-off-by: Gao Xiang <hsiangkao@linux.alibaba.com>
---
v8: https://lore.kernel.org/r/20210726145734.214295-1-hsiangkao@linux.alibaba.com
changes since v8:
 - update the subject to 'iomap: Support file tail packing' as there
   are clearly a number of ways to make the inline data support more
   flexible (Matthew);

 - add one extra safety check (Darrick):
	if (WARN_ON_ONCE(size > iomap->length))
		return -EIO;

 fs/iomap/buffered-io.c | 42 ++++++++++++++++++++++++++++++------------
 fs/iomap/direct-io.c   | 10 ++++++----
 include/linux/iomap.h  | 18 ++++++++++++++++++
 3 files changed, 54 insertions(+), 16 deletions(-)

diff --git a/fs/iomap/buffered-io.c b/fs/iomap/buffered-io.c
index 87ccb3438bec..f429b9d87dbe 100644
--- a/fs/iomap/buffered-io.c
+++ b/fs/iomap/buffered-io.c
@@ -205,25 +205,32 @@ struct iomap_readpage_ctx {
 	struct readahead_control *rac;
 };
 
-static void
-iomap_read_inline_data(struct inode *inode, struct page *page,
+static int iomap_read_inline_data(struct inode *inode, struct page *page,
 		struct iomap *iomap)
 {
-	size_t size = i_size_read(inode);
+	size_t size = i_size_read(inode) - iomap->offset;
 	void *addr;
 
 	if (PageUptodate(page))
-		return;
+		return 0;
 
-	BUG_ON(page_has_private(page));
-	BUG_ON(page->index);
-	BUG_ON(size > PAGE_SIZE - offset_in_page(iomap->inline_data));
+	/* inline data must start page aligned in the file */
+	if (WARN_ON_ONCE(offset_in_page(iomap->offset)))
+		return -EIO;
+	if (WARN_ON_ONCE(size > PAGE_SIZE -
+			 offset_in_page(iomap->inline_data)))
+		return -EIO;
+	if (WARN_ON_ONCE(size > iomap->length))
+		return -EIO;
+	if (WARN_ON_ONCE(page_has_private(page)))
+		return -EIO;
 
 	addr = kmap_atomic(page);
 	memcpy(addr, iomap->inline_data, size);
 	memset(addr + size, 0, PAGE_SIZE - size);
 	kunmap_atomic(addr);
 	SetPageUptodate(page);
+	return 0;
 }
 
 static inline bool iomap_block_needs_zeroing(struct inode *inode,
@@ -247,8 +254,10 @@ iomap_readpage_actor(struct inode *inode, loff_t pos, loff_t length, void *data,
 	sector_t sector;
 
 	if (iomap->type == IOMAP_INLINE) {
-		WARN_ON_ONCE(pos);
-		iomap_read_inline_data(inode, page, iomap);
+		int ret = iomap_read_inline_data(inode, page, iomap);
+
+		if (ret)
+			return ret;
 		return PAGE_SIZE;
 	}
 
@@ -589,6 +598,15 @@ __iomap_write_begin(struct inode *inode, loff_t pos, unsigned len, int flags,
 	return 0;
 }
 
+static int iomap_write_begin_inline(struct inode *inode,
+		struct page *page, struct iomap *srcmap)
+{
+	/* needs more work for the tailpacking case, disable for now */
+	if (WARN_ON_ONCE(srcmap->offset != 0))
+		return -EIO;
+	return iomap_read_inline_data(inode, page, srcmap);
+}
+
 static int
 iomap_write_begin(struct inode *inode, loff_t pos, unsigned len, unsigned flags,
 		struct page **pagep, struct iomap *iomap, struct iomap *srcmap)
@@ -618,7 +636,7 @@ iomap_write_begin(struct inode *inode, loff_t pos, unsigned len, unsigned flags,
 	}
 
 	if (srcmap->type == IOMAP_INLINE)
-		iomap_read_inline_data(inode, page, srcmap);
+		status = iomap_write_begin_inline(inode, page, srcmap);
 	else if (iomap->flags & IOMAP_F_BUFFER_HEAD)
 		status = __block_write_begin_int(page, pos, len, NULL, srcmap);
 	else
@@ -671,11 +689,11 @@ static size_t iomap_write_end_inline(struct inode *inode, struct page *page,
 	void *addr;
 
 	WARN_ON_ONCE(!PageUptodate(page));
-	BUG_ON(pos + copied > PAGE_SIZE - offset_in_page(iomap->inline_data));
+	BUG_ON(!iomap_inline_data_valid(iomap));
 
 	flush_dcache_page(page);
 	addr = kmap_atomic(page);
-	memcpy(iomap->inline_data + pos, addr + pos, copied);
+	memcpy(iomap_inline_data(iomap, pos), addr + pos, copied);
 	kunmap_atomic(addr);
 
 	mark_inode_dirty(inode);
diff --git a/fs/iomap/direct-io.c b/fs/iomap/direct-io.c
index 9398b8c31323..41ccbfc9dc82 100644
--- a/fs/iomap/direct-io.c
+++ b/fs/iomap/direct-io.c
@@ -378,23 +378,25 @@ iomap_dio_inline_actor(struct inode *inode, loff_t pos, loff_t length,
 		struct iomap_dio *dio, struct iomap *iomap)
 {
 	struct iov_iter *iter = dio->submit.iter;
+	void *inline_data = iomap_inline_data(iomap, pos);
 	size_t copied;
 
-	BUG_ON(pos + length > PAGE_SIZE - offset_in_page(iomap->inline_data));
+	if (WARN_ON_ONCE(!iomap_inline_data_valid(iomap)))
+		return -EIO;
 
 	if (dio->flags & IOMAP_DIO_WRITE) {
 		loff_t size = inode->i_size;
 
 		if (pos > size)
-			memset(iomap->inline_data + size, 0, pos - size);
-		copied = copy_from_iter(iomap->inline_data + pos, length, iter);
+			memset(iomap_inline_data(iomap, size), 0, pos - size);
+		copied = copy_from_iter(inline_data, length, iter);
 		if (copied) {
 			if (pos + copied > size)
 				i_size_write(inode, pos + copied);
 			mark_inode_dirty(inode);
 		}
 	} else {
-		copied = copy_to_iter(iomap->inline_data + pos, length, iter);
+		copied = copy_to_iter(inline_data, length, iter);
 	}
 	dio->size += copied;
 	return copied;
diff --git a/include/linux/iomap.h b/include/linux/iomap.h
index 479c1da3e221..b8ec145b2975 100644
--- a/include/linux/iomap.h
+++ b/include/linux/iomap.h
@@ -97,6 +97,24 @@ iomap_sector(struct iomap *iomap, loff_t pos)
 	return (iomap->addr + pos - iomap->offset) >> SECTOR_SHIFT;
 }
 
+/*
+ * Returns the inline data pointer for logical offset @pos.
+ */
+static inline void *iomap_inline_data(struct iomap *iomap, loff_t pos)
+{
+	return iomap->inline_data + pos - iomap->offset;
+}
+
+/*
+ * Check if the mapping's length is within the valid range for inline data.
+ * This is used to guard against accessing data beyond the page inline_data
+ * points at.
+ */
+static inline bool iomap_inline_data_valid(struct iomap *iomap)
+{
+	return iomap->length <= PAGE_SIZE - offset_in_page(iomap->inline_data);
+}
+
 /*
  * When a filesystem sets page_ops in an iomap mapping it returns, page_prepare
  * and page_done will be called for each page written to.  This only applies to
-- 
2.24.4


^ permalink raw reply related	[flat|nested] 414+ messages in thread
* (no subject)
@ 2021-06-06 19:19 Davidlohr Bueso
  2021-06-07 16:02 ` André Almeida
  0 siblings, 1 reply; 414+ messages in thread
From: Davidlohr Bueso @ 2021-06-06 19:19 UTC (permalink / raw)
  To: Andr� Almeida
  Cc: Thomas Gleixner, Ingo Molnar, Peter Zijlstra, Darren Hart,
	linux-kernel, Steven Rostedt, Sebastian Andrzej Siewior, kernel,
	krisman, pgriffais, z.figura12, joel, malteskarupke, linux-api,
	fweimer, libc-alpha, linux-kselftest, shuah, acme, corbet,
	Peter Oskolkov, Andrey Semashev, mtk.manpages

Bcc:
Subject: Re: [PATCH v4 07/15] docs: locking: futex2: Add documentation
Reply-To:
In-Reply-To: <20210603195924.361327-8-andrealmeid@collabora.com>

On Thu, 03 Jun 2021, Andr� Almeida wrote:

>Add a new documentation file specifying both userspace API and internal
>implementation details of futex2 syscalls.

I think equally important would be to provide a manpage for each new
syscall you are introducing, and keep mkt in the loop as in the past he
extensively documented and improved futex manpages, and overall has a
lot of experience with dealing with kernel interfaces.

Thanks,
Davidlohr

>
>Signed-off-by: André Almeida <andrealmeid@collabora.com>
>---
> Documentation/locking/futex2.rst | 198 +++++++++++++++++++++++++++++++
> Documentation/locking/index.rst  |   1 +
> 2 files changed, 199 insertions(+)
> create mode 100644 Documentation/locking/futex2.rst
>
>diff --git a/Documentation/locking/futex2.rst b/Documentation/locking/futex2.rst
>new file mode 100644
>index 000000000000..2f74d7c97a55
>--- /dev/null
>+++ b/Documentation/locking/futex2.rst
>@@ -0,0 +1,198 @@
>+.. SPDX-License-Identifier: GPL-2.0
>+
>+======
>+futex2
>+======
>+
>+:Author: André Almeida <andrealmeid@collabora.com>
>+
>+futex, or fast user mutex, is a set of syscalls to allow userspace to create
>+performant synchronization mechanisms, such as mutexes, semaphores and
>+conditional variables in userspace. C standard libraries, like glibc, uses it
>+as a means to implement more high level interfaces like pthreads.
>+
>+The interface
>+=============
>+
>+uAPI functions
>+--------------
>+
>+.. kernel-doc:: kernel/futex2.c
>+   :identifiers: sys_futex_wait sys_futex_wake sys_futex_waitv sys_futex_requeue
>+
>+uAPI structures
>+---------------
>+
>+.. kernel-doc:: include/uapi/linux/futex.h
>+
>+The ``flag`` argument
>+---------------------
>+
>+The flag is used to specify the size of the futex word
>+(FUTEX_[8, 16, 32, 64]). It's mandatory to define one, since there's no
>+default size.
>+
>+By default, the timeout uses a monotonic clock, but can be used as a realtime
>+one by using the FUTEX_REALTIME_CLOCK flag.
>+
>+By default, futexes are of the private type, that means that this user address
>+will be accessed by threads that share the same memory region. This allows for
>+some internal optimizations, so they are faster. However, if the address needs
>+to be shared with different processes (like using ``mmap()`` or ``shm()``), they
>+need to be defined as shared and the flag FUTEX_SHARED_FLAG is used to set that.
>+
>+By default, the operation has no NUMA-awareness, meaning that the user can't
>+choose the memory node where the kernel side futex data will be stored. The
>+user can choose the node where it wants to operate by setting the
>+FUTEX_NUMA_FLAG and using the following structure (where X can be 8, 16, 32 or
>+64)::
>+
>+ struct futexX_numa {
>+         __uX value;
>+         __sX hint;
>+ };
>+
>+This structure should be passed at the ``void *uaddr`` of futex functions. The
>+address of the structure will be used to be waited on/waken on, and the
>+``value`` will be compared to ``val`` as usual. The ``hint`` member is used to
>+define which node the futex will use. When waiting, the futex will be
>+registered on a kernel-side table stored on that node; when waking, the futex
>+will be searched for on that given table. That means that there's no redundancy
>+between tables, and the wrong ``hint`` value will lead to undesired behavior.
>+Userspace is responsible for dealing with node migrations issues that may
>+occur. ``hint`` can range from [0, MAX_NUMA_NODES), for specifying a node, or
>+-1, to use the same node the current process is using.
>+
>+When not using FUTEX_NUMA_FLAG on a NUMA system, the futex will be stored on a
>+global table on allocated on the first node.
>+
>+The ``timo`` argument
>+---------------------
>+
>+As per the Y2038 work done in the kernel, new interfaces shouldn't add timeout
>+options known to be buggy. Given that, ``timo`` should be a 64-bit timeout at
>+all platforms, using an absolute timeout value.
>+
>+Implementation
>+==============
>+
>+The internal implementation follows a similar design to the original futex.
>+Given that we want to replicate the same external behavior of current futex,
>+this should be somewhat expected.
>+
>+Waiting
>+-------
>+
>+For the wait operations, they are all treated as if you want to wait on N
>+futexes, so the path for futex_wait and futex_waitv is the basically the same.
>+For both syscalls, the first step is to prepare an internal list for the list
>+of futexes to wait for (using struct futexv_head). For futex_wait() calls, this
>+list will have a single object.
>+
>+We have a hash table, where waiters register themselves before sleeping. Then
>+the wake function checks this table looking for waiters at uaddr.  The hash
>+bucket to be used is determined by a struct futex_key, that stores information
>+to uniquely identify an address from a given process. Given the huge address
>+space, there'll be hash collisions, so we store information to be later used on
>+collision treatment.
>+
>+First, for every futex we want to wait on, we check if (``*uaddr == val``).
>+This check is done holding the bucket lock, so we are correctly serialized with
>+any futex_wake() calls. If any waiter fails the check above, we dequeue all
>+futexes. The check (``*uaddr == val``) can fail for two reasons:
>+
>+- The values are different, and we return -EAGAIN. However, if while
>+  dequeueing we found that some futexes were awakened, we prioritize this
>+  and return success.
>+
>+- When trying to access the user address, we do so with page faults
>+  disabled because we are holding a bucket's spin lock (and can't sleep
>+  while holding a spin lock). If there's an error, it might be a page
>+  fault, or an invalid address. We release the lock, dequeue everyone
>+  (because it's illegal to sleep while there are futexes enqueued, we
>+  could lose wakeups) and try again with page fault enabled. If we
>+  succeed, this means that the address is valid, but we need to do
>+  all the work again. For serialization reasons, we need to have the
>+  spin lock when getting the user value. Additionally, for shared
>+  futexes, we also need to recalculate the hash, since the underlying
>+  mapping mechanisms could have changed when dealing with page fault.
>+  If, even with page fault enabled, we can't access the address, it
>+  means it's an invalid user address, and we return -EFAULT. For this
>+  case, we prioritize the error, even if some futexes were awaken.
>+
>+If the check is OK, they are enqueued on a linked list in our bucket, and
>+proceed to the next one. If all waiters succeed, we put the thread to sleep
>+until a futex_wake() call, timeout expires or we get a signal. After waking up,
>+we dequeue everyone, and check if some futex was awakened. This dequeue is done
>+by iteratively walking at each element of struct futex_head list.
>+
>+All enqueuing/dequeuing operations requires to hold the bucket lock, to avoid
>+racing while modifying the list.
>+
>+Waking
>+------
>+
>+We get the bucket that's storing the waiters at uaddr, and wake the required
>+number of waiters, checking for hash collision.
>+
>+There's an optimization that makes futex_wake() not take the bucket lock if
>+there's no one to be woken on that bucket. It checks an atomic counter that each
>+bucket has, if it says 0, then the syscall exits. In order for this to work, the
>+waiter thread increases it before taking the lock, so the wake thread will
>+correctly see that there's someone waiting and will continue the path to take
>+the bucket lock. To get the correct serialization, the waiter issues a memory
>+barrier after increasing the bucket counter and the waker issues a memory
>+barrier before checking it.
>+
>+Requeuing
>+---------
>+
>+The requeue path first checks for each struct futex_requeue and their flags.
>+Then, it will compare the expected value with the one at uaddr1::uaddr.
>+Following the same serialization explained at Waking_, we increase the atomic
>+counter for the bucket of uaddr2 before taking the lock. We need to have both
>+buckets locks at same time so we don't race with other futex operation. To
>+ensure the locks are taken in the same order for all threads (and thus avoiding
>+deadlocks), every requeue operation takes the "smaller" bucket first, when
>+comparing both addresses.
>+
>+If the compare with user value succeeds, we proceed by waking ``nr_wake``
>+futexes, and then requeuing ``nr_requeue`` from bucket of uaddr1 to the uaddr2.
>+This consists in a simple list deletion/addition and replacing the old futex key
>+with the new one.
>+
>+Futex keys
>+----------
>+
>+There are two types of futexes: private and shared ones. The private are futexes
>+meant to be used by threads that share the same memory space, are easier to be
>+uniquely identified and thus can have some performance optimization. The
>+elements for identifying one are: the start address of the page where the
>+address is, the address offset within the page and the current->mm pointer.
>+
>+Now, for uniquely identifying a shared futex:
>+
>+- If the page containing the user address is an anonymous page, we can
>+  just use the same data used for private futexes (the start address of
>+  the page, the address offset within the page and the current->mm
>+  pointer); that will be enough for uniquely identifying such futex. We
>+  also set one bit at the key to differentiate if a private futex is
>+  used on the same address (mixing shared and private calls does not
>+  work).
>+
>+- If the page is file-backed, current->mm maybe isn't the same one for
>+  every user of this futex, so we need to use other data: the
>+  page->index, a UUID for the struct inode and the offset within the
>+  page.
>+
>+Note that members of futex_key don't have any particular meaning after they
>+are part of the struct - they are just bytes to identify a futex.  Given that,
>+we don't need to use a particular name or type that matches the original data,
>+we only need to care about the bitsize of each component and make both private
>+and shared fit in the same memory space.
>+
>+Source code documentation
>+=========================
>+
>+.. kernel-doc:: kernel/futex2.c
>+   :no-identifiers: sys_futex_wait sys_futex_wake sys_futex_waitv sys_futex_requeue
>diff --git a/Documentation/locking/index.rst b/Documentation/locking/index.rst
>index 7003bd5aeff4..9bf03c7fa1ec 100644
>--- a/Documentation/locking/index.rst
>+++ b/Documentation/locking/index.rst
>@@ -24,6 +24,7 @@ locking
>     percpu-rw-semaphore
>     robust-futexes
>     robust-futex-ABI
>+    futex2
>
> .. only::  subproject and html
>
>--
>2.31.1
>

^ permalink raw reply	[flat|nested] 414+ messages in thread
* (no subject)
@ 2021-04-05  0:01 Mitali Borkar
  2021-04-06  7:03 ` Arnd Bergmann
  0 siblings, 1 reply; 414+ messages in thread
From: Mitali Borkar @ 2021-04-05  0:01 UTC (permalink / raw)
  To: manish, GR-Linux-NIC-Dev, gregkh; +Cc: linux-staging, linux-kernel

outreachy-kernel@googlegroups.com, mitaliborkar810@gmail.com 
Bcc: 
Subject: [PATCH] staging: qlge:remove else after break
Reply-To: 

Fixed Warning:- else is not needed after break
break terminates the loop if encountered. else is unnecessary and
increases indenatation

Signed-off-by: Mitali Borkar <mitaliborkar810@gmail.com>
---
 drivers/staging/qlge/qlge_mpi.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/staging/qlge/qlge_mpi.c b/drivers/staging/qlge/qlge_mpi.c
index 2630ebf50341..3a49f187203b 100644
--- a/drivers/staging/qlge/qlge_mpi.c
+++ b/drivers/staging/qlge/qlge_mpi.c
@@ -935,13 +935,11 @@ static int qlge_idc_wait(struct qlge_adapter *qdev)
 			netif_err(qdev, drv, qdev->ndev, "IDC Success.\n");
 			status = 0;
 			break;
-		} else {
-			netif_err(qdev, drv, qdev->ndev,
+		}	netif_err(qdev, drv, qdev->ndev,
 				  "IDC: Invalid State 0x%.04x.\n",
 				  mbcp->mbox_out[0]);
 			status = -EIO;
 			break;
-		}
 	}
 
 	return status;
-- 
2.30.2


^ permalink raw reply related	[flat|nested] 414+ messages in thread
[parent not found: <CAPncsNOFoUt7uEDEdihDTZY4pJsuPxt146W-L+Ju53SgZ6ezYw@mail.gmail.com>]
* (no subject)
@ 2021-01-19  0:10 David Howells
  2021-01-20 14:46 ` Jarkko Sakkinen
  0 siblings, 1 reply; 414+ messages in thread
From: David Howells @ 2021-01-19  0:10 UTC (permalink / raw)
  To: torvalds
  Cc: Tobias Markus, Tianjia Zhang, dhowells, keyrings, linux-crypto,
	linux-security-module, stable, linux-kernel


From: Tianjia Zhang <tianjia.zhang@linux.alibaba.com>

On the following call path, `sig->pkey_algo` is not assigned
in asymmetric_key_verify_signature(), which causes runtime
crash in public_key_verify_signature().

  keyctl_pkey_verify
    asymmetric_key_verify_signature
      verify_signature
        public_key_verify_signature

This patch simply check this situation and fixes the crash
caused by NULL pointer.

Fixes: 215525639631 ("X.509: support OSCCA SM2-with-SM3 certificate verification")
Reported-by: Tobias Markus <tobias@markus-regensburg.de>
Signed-off-by: Tianjia Zhang <tianjia.zhang@linux.alibaba.com>
Signed-off-by: David Howells <dhowells@redhat.com>
Reviewed-and-tested-by: Toke Høiland-Jørgensen <toke@redhat.com>
Tested-by: João Fonseca <jpedrofonseca@ua.pt>
Cc: stable@vger.kernel.org # v5.10+
---

 crypto/asymmetric_keys/public_key.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/crypto/asymmetric_keys/public_key.c b/crypto/asymmetric_keys/public_key.c
index 8892908ad58c..788a4ba1e2e7 100644
--- a/crypto/asymmetric_keys/public_key.c
+++ b/crypto/asymmetric_keys/public_key.c
@@ -356,7 +356,8 @@ int public_key_verify_signature(const struct public_key *pkey,
 	if (ret)
 		goto error_free_key;
 
-	if (strcmp(sig->pkey_algo, "sm2") == 0 && sig->data_size) {
+	if (sig->pkey_algo && strcmp(sig->pkey_algo, "sm2") == 0 &&
+	    sig->data_size) {
 		ret = cert_sig_digest_update(sig, tfm);
 		if (ret)
 			goto error_free_key;


^ permalink raw reply related	[flat|nested] 414+ messages in thread
[parent not found: <CAGMNF6W8baS_zLYL8DwVsbfPWTP2ohzRB7xutW0X=MUzv93pbA@mail.gmail.com>]
* [PATCH] lib/find_bit: Add find_prev_*_bit functions.
@ 2020-12-02  1:10 Yun Levi
  2020-12-02  9:47 ` Andy Shevchenko
  0 siblings, 1 reply; 414+ messages in thread
From: Yun Levi @ 2020-12-02  1:10 UTC (permalink / raw)
  To: dushistov, arnd, akpm, gustavo, vilhelm.gray, richard.weiyang,
	andriy.shevchenko, joseph.qi, skalluru, yury.norov, jpoimboe
  Cc: linux-kernel, linux-arch

Inspired find_next_*bit function series, add find_prev_*_bit series.
I'm not sure whether it'll be used right now But, I add these functions
for future usage.

Signed-off-by: Levi Yun <ppbuk5246@gmail.com>
---
 fs/ufs/util.h                     |  24 +++---
 include/asm-generic/bitops/find.h |  69 ++++++++++++++++
 include/asm-generic/bitops/le.h   |  33 ++++++++
 include/linux/bitops.h            |  34 +++++---
 lib/find_bit.c                    | 126 +++++++++++++++++++++++++++++-
 5 files changed, 260 insertions(+), 26 deletions(-)

diff --git a/fs/ufs/util.h b/fs/ufs/util.h
index 4931bec1a01c..7c87c77d10ca 100644
--- a/fs/ufs/util.h
+++ b/fs/ufs/util.h
@@ -2,7 +2,7 @@
 /*
  *  linux/fs/ufs/util.h
  *
- * Copyright (C) 1998
+ * Copyright (C) 1998
  * Daniel Pirkl <daniel.pirkl@email.cz>
  * Charles University, Faculty of Mathematics and Physics
  */
@@ -263,7 +263,7 @@ extern int ufs_prepare_chunk(struct page *page,
loff_t pos, unsigned len);
 /*
  * These functions manipulate ufs buffers
  */
-#define ubh_bread(sb,fragment,size) _ubh_bread_(uspi,sb,fragment,size)
+#define ubh_bread(sb,fragment,size) _ubh_bread_(uspi,sb,fragment,size)
 extern struct ufs_buffer_head * _ubh_bread_(struct
ufs_sb_private_info *, struct super_block *, u64 , u64);
 extern struct ufs_buffer_head * ubh_bread_uspi(struct
ufs_sb_private_info *, struct super_block *, u64, u64);
 extern void ubh_brelse (struct ufs_buffer_head *);
@@ -296,7 +296,7 @@ static inline void *get_usb_offset(struct
ufs_sb_private_info *uspi,
                                   unsigned int offset)
 {
        unsigned int index;
-
+
        index = offset >> uspi->s_fshift;
        offset &= ~uspi->s_fmask;
        return uspi->s_ubh.bh[index]->b_data + offset;
@@ -411,9 +411,9 @@ static inline unsigned _ubh_find_next_zero_bit_(
                offset = 0;
        }
        return (base << uspi->s_bpfshift) + pos - begin;
-}
+}

-static inline unsigned find_last_zero_bit (unsigned char * bitmap,
+static inline unsigned __ubh_find_last_zero_bit(unsigned char * bitmap,
        unsigned size, unsigned offset)
 {
        unsigned bit, i;
@@ -453,7 +453,7 @@ static inline unsigned _ubh_find_last_zero_bit_(
                            size + (uspi->s_bpf - start), uspi->s_bpf)
                        - (uspi->s_bpf - start);
                size -= count;
-               pos = find_last_zero_bit (ubh->bh[base]->b_data,
+               pos = __ubh_find_last_zero_bit(ubh->bh[base]->b_data,
                        start, start - count);
                if (pos > start - count || !size)
                        break;
@@ -461,7 +461,7 @@ static inline unsigned _ubh_find_last_zero_bit_(
                start = uspi->s_bpf;
        }
        return (base << uspi->s_bpfshift) + pos - begin;
-}
+}

 #define ubh_isblockclear(ubh,begin,block)
(!_ubh_isblockset_(uspi,ubh,begin,block))

@@ -483,7 +483,7 @@ static inline int _ubh_isblockset_(struct
ufs_sb_private_info * uspi,
                mask = 0x01 << (block & 0x07);
                return (*ubh_get_addr (ubh, begin + (block >> 3)) &
mask) == mask;
        }
-       return 0;
+       return 0;
 }

 #define ubh_clrblock(ubh,begin,block) _ubh_clrblock_(uspi,ubh,begin,block)
@@ -492,8 +492,8 @@ static inline void _ubh_clrblock_(struct
ufs_sb_private_info * uspi,
 {
        switch (uspi->s_fpb) {
        case 8:
-               *ubh_get_addr (ubh, begin + block) = 0x00;
-               return;
+               *ubh_get_addr (ubh, begin + block) = 0x00;
+               return;
        case 4:
                *ubh_get_addr (ubh, begin + (block >> 1)) &= ~(0x0f <<
((block & 0x01) << 2));
                return;
@@ -531,9 +531,9 @@ static inline void ufs_fragacct (struct
super_block * sb, unsigned blockmap,
 {
        struct ufs_sb_private_info * uspi;
        unsigned fragsize, pos;
-
+
        uspi = UFS_SB(sb)->s_uspi;
-
+
        fragsize = 0;
        for (pos = 0; pos < uspi->s_fpb; pos++) {
                if (blockmap & (1 << pos)) {
diff --git a/include/asm-generic/bitops/find.h
b/include/asm-generic/bitops/find.h
index 9fdf21302fdf..ca18b2ec954c 100644
--- a/include/asm-generic/bitops/find.h
+++ b/include/asm-generic/bitops/find.h
@@ -16,6 +16,20 @@ extern unsigned long find_next_bit(const unsigned
long *addr, unsigned long
                size, unsigned long offset);
 #endif

+#ifndef find_prev_bit
+/**
+ * find_prev_bit - find the prev set bit in a memory region
+ * @addr: The address to base the search on
+ * @offset: The bitnumber to start searching at
+ * @size: The bitmap size in bits
+ *
+ * Returns the bit number for the prev set bit
+ * If no bits are set, returns @size.
+ */
+extern unsigned long find_prev_bit(const unsigned long *addr, unsigned long
+               size, unsigned long offset);
+#endif
+
 #ifndef find_next_and_bit
 /**
  * find_next_and_bit - find the next set bit in both memory regions
@@ -32,6 +46,22 @@ extern unsigned long find_next_and_bit(const
unsigned long *addr1,
                unsigned long offset);
 #endif

+#ifndef find_prev_and_bit
+/**
+ * find_prev_and_bit - find the prev set bit in both memory regions
+ * @addr1: The first address to base the search on
+ * @addr2: The second address to base the search on
+ * @offset: The bitnumber to start searching at
+ * @size: The bitmap size in bits
+ *
+ * Returns the bit number for the prev set bit
+ * If no bits are set, returns @size.
+ */
+extern unsigned long find_prev_and_bit(const unsigned long *addr1,
+               const unsigned long *addr2, unsigned long size,
+               unsigned long offset);
+#endif
+
 #ifndef find_next_zero_bit
 /**
  * find_next_zero_bit - find the next cleared bit in a memory region
@@ -46,6 +76,20 @@ extern unsigned long find_next_zero_bit(const
unsigned long *addr, unsigned
                long size, unsigned long offset);
 #endif

+#ifndef find_prev_zero_bit
+/**
+ * find_prev_zero_bit - find the prev cleared bit in a memory region
+ * @addr: The address to base the search on
+ * @offset: The bitnumber to start searching at
+ * @size: The bitmap size in bits
+ *
+ * Returns the bit number of the prev zero bit
+ * If no bits are zero, returns @size.
+ */
+extern unsigned long find_prev_zero_bit(const unsigned long *addr, unsigned
+               long size, unsigned long offset);
+#endif
+
 #ifdef CONFIG_GENERIC_FIND_FIRST_BIT

 /**
@@ -80,6 +124,31 @@ extern unsigned long find_first_zero_bit(const
unsigned long *addr,

 #endif /* CONFIG_GENERIC_FIND_FIRST_BIT */

+#ifndef find_last_bit
+/**
+ * find_last_bit - find the last set bit in a memory region
+ * @addr: The address to start the search at
+ * @size: The number of bits to search
+ *
+ * Returns the bit number of the last set bit, or size.
+ */
+extern unsigned long find_last_bit(const unsigned long *addr,
+                                  unsigned long size);
+#endif
+
+#ifndef find_last_zero_bit
+/**
+ * find_last_zero_bit - find the last cleared bit in a memory region
+ * @addr: The address to start the search at
+ * @size: The maximum number of bits to search
+ *
+ * Returns the bit number of the first cleared bit.
+ * If no bits are zero, returns @size.
+ */
+extern unsigned long find_last_zero_bit(const unsigned long *addr,
+                                        unsigned long size);
+#endif
+
 /**
  * find_next_clump8 - find next 8-bit clump with set bits in a memory region
  * @clump: location to store copy of found clump
diff --git a/include/asm-generic/bitops/le.h b/include/asm-generic/bitops/le.h
index 188d3eba3ace..d0bd15bc34d9 100644
--- a/include/asm-generic/bitops/le.h
+++ b/include/asm-generic/bitops/le.h
@@ -27,6 +27,24 @@ static inline unsigned long
find_first_zero_bit_le(const void *addr,
        return find_first_zero_bit(addr, size);
 }

+static inline unsigned long find_prev_zero_bit_le(const void *addr,
+               unsigned long size, unsigned long offset)
+{
+       return find_prev_zero_bit(addr, size, offset);
+}
+
+static inline unsigned long find_prev_bit_le(const void *addr,
+               unsigned long size, unsigned long offset)
+{
+       return find_prev_bit(addr, size, offset);
+}
+
+static inline unsigned long find_last_zero_bit_le(const void *addr,
+               unsigned long size)
+{
+       return find_last_zero_bit(addr, size);
+}
+
 #elif defined(__BIG_ENDIAN)

 #define BITOP_LE_SWIZZLE       ((BITS_PER_LONG-1) & ~0x7)
@@ -41,11 +59,26 @@ extern unsigned long find_next_bit_le(const void *addr,
                unsigned long size, unsigned long offset);
 #endif

+#ifndef find_prev_zero_bit_le
+extern unsigned long find_prev_zero_bit_le(const void *addr,
+               unsigned long size, unsigned long offset);
+#endif
+
+#ifndef find_prev_bit_le
+extern unsigned long find_prev_bit_le(const void *addr,
+               unsigned long size, unsigned long offset);
+#endif
+
 #ifndef find_first_zero_bit_le
 #define find_first_zero_bit_le(addr, size) \
        find_next_zero_bit_le((addr), (size), 0)
 #endif

+#ifndef find_last_zero_bit_le
+#define find_last_zero_bit_le(addr, size) \
+       find_prev_zero_bit_le((addr), (size), (size - 1))
+#endif
+
 #else
 #error "Please fix <asm/byteorder.h>"
 #endif
diff --git a/include/linux/bitops.h b/include/linux/bitops.h
index 5b74bdf159d6..124c68929861 100644
--- a/include/linux/bitops.h
+++ b/include/linux/bitops.h
@@ -50,6 +50,28 @@ extern unsigned long __sw_hweight64(__u64 w);
             (bit) < (size);                                    \
             (bit) = find_next_zero_bit((addr), (size), (bit) + 1))

+#define for_each_set_bit_reverse(bit, addr, size) \
+       for ((bit) = find_last_bit((addr), (size));             \
+            (bit) < (size);                                    \
+            (bit) = find_prev_bit((addr), (size), (bit)))
+
+/* same as for_each_set_bit_reverse() but use bit as value to start with */
+#define for_each_set_bit_from_reverse(bit, addr, size) \
+       for ((bit) = find_prev_bit((addr), (size), (bit));      \
+            (bit) < (size);                                    \
+            (bit) = find_prev_bit((addr), (size), (bit - 1)))
+
+#define for_each_clear_bit_reverse(bit, addr, size) \
+       for ((bit) = find_last_zero_bit((addr), (size));        \
+            (bit) < (size);                                    \
+            (bit) = find_prev_zero_bit((addr), (size), (bit)))
+
+/* same as for_each_clear_bit_reverse() but use bit as value to start with */
+#define for_each_clear_bit_from_reverse(bit, addr, size) \
+       for ((bit) = find_prev_zero_bit((addr), (size), (bit)); \
+            (bit) < (size);                                    \
+            (bit) = find_next_zero_bit((addr), (size), (bit - 1)))
+
 /**
  * for_each_set_clump8 - iterate over bitmap for each 8-bit clump with set bits
  * @start: bit offset to start search and to store the current iteration offset
@@ -283,17 +305,5 @@ static __always_inline void __assign_bit(long nr,
volatile unsigned long *addr,
 })
 #endif

-#ifndef find_last_bit
-/**
- * find_last_bit - find the last set bit in a memory region
- * @addr: The address to start the search at
- * @size: The number of bits to search
- *
- * Returns the bit number of the last set bit, or size.
- */
-extern unsigned long find_last_bit(const unsigned long *addr,
-                                  unsigned long size);
-#endif
-
 #endif /* __KERNEL__ */
 #endif
diff --git a/lib/find_bit.c b/lib/find_bit.c
index 4a8751010d59..cbe06abd3d21 100644
--- a/lib/find_bit.c
+++ b/lib/find_bit.c
@@ -69,6 +69,58 @@ static unsigned long _find_next_bit(const unsigned
long *addr1,
 }
 #endif

+#if !defined(find_prev_bit) || !defined(find_prev_zero_bit) ||
         \
+       !defined(find_prev_bit_le) || !defined(find_prev_zero_bit_le)
||        \
+       !defined(find_prev_and_bit)
+/*
+ * This is a common helper function for find_prev_bit, find_prev_zero_bit, and
+ * find_prev_and_bit. The differences are:
+ *  - The "invert" argument, which is XORed with each fetched word before
+ *    searching it for one bits.
+ *  - The optional "addr2", which is anded with "addr1" if present.
+ */
+static unsigned long _find_prev_bit(const unsigned long *addr1,
+               const unsigned long *addr2, unsigned long nbits,
+               unsigned long start, unsigned long invert, unsigned long le)
+{
+       unsigned long tmp, mask;
+
+       if (unlikely(start >= nbits))
+               return nbits;
+
+       tmp = addr1[start / BITS_PER_LONG];
+       if (addr2)
+               tmp &= addr2[start / BITS_PER_LONG];
+       tmp ^= invert;
+
+       /* Handle 1st word. */
+       mask = BITMAP_LAST_WORD_MASK(start + 1);
+       if (le)
+               mask = swab(mask);
+
+       tmp &= mask;
+
+       start = round_down(start, BITS_PER_LONG);
+
+       while (!tmp) {
+               start -= BITS_PER_LONG;
+               if (start >= nbits)
+                       return nbits;
+
+               tmp = addr1[start / BITS_PER_LONG];
+               if (addr2)
+                       tmp &= addr2[start / BITS_PER_LONG];
+               tmp ^= invert;
+       }
+
+       if (le)
+               tmp = swab(tmp);
+
+       return start + __fls(tmp);
+}
+#endif
+
+
 #ifndef find_next_bit
 /*
  * Find the next set bit in a memory region.
@@ -81,6 +133,18 @@ unsigned long find_next_bit(const unsigned long
*addr, unsigned long size,
 EXPORT_SYMBOL(find_next_bit);
 #endif

+#ifndef find_prev_bit
+/*
+ * Find the prev set bit in a memory region.
+ */
+unsigned long find_prev_bit(const unsigned long *addr, unsigned long size,
+                           unsigned long offset)
+{
+       return _find_prev_bit(addr, NULL, size, offset, 0UL, 0);
+}
+EXPORT_SYMBOL(find_prev_bit);
+#endif
+
 #ifndef find_next_zero_bit
 unsigned long find_next_zero_bit(const unsigned long *addr, unsigned long size,
                                 unsigned long offset)
@@ -90,7 +154,16 @@ unsigned long find_next_zero_bit(const unsigned
long *addr, unsigned long size,
 EXPORT_SYMBOL(find_next_zero_bit);
 #endif

-#if !defined(find_next_and_bit)
+#ifndef find_prev_zero_bit
+unsigned long find_prev_zero_bit(const unsigned long *addr, unsigned long size,
+                                unsigned long offset)
+{
+       return _find_prev_bit(addr, NULL, size, offset, ~0UL, 0);
+}
+EXPORT_SYMBOL(find_prev_zero_bit);
+#endif
+
+#ifndef find_next_and_bit
 unsigned long find_next_and_bit(const unsigned long *addr1,
                const unsigned long *addr2, unsigned long size,
                unsigned long offset)
@@ -100,6 +173,16 @@ unsigned long find_next_and_bit(const unsigned long *addr1,
 EXPORT_SYMBOL(find_next_and_bit);
 #endif

+#ifndef find_prev_and_bit
+unsigned long find_prev_and_bit(const unsigned long *addr1,
+               const unsigned long *addr2, unsigned long size,
+               unsigned long offset)
+{
+       return _find_prev_bit(addr1, addr2, size, offset, 0UL, 0);
+}
+EXPORT_SYMBOL(find_prev_and_bit);
+#endif
+
 #ifndef find_first_bit
 /*
  * Find the first set bit in a memory region.
@@ -141,7 +224,7 @@ unsigned long find_last_bit(const unsigned long
*addr, unsigned long size)
 {
        if (size) {
                unsigned long val = BITMAP_LAST_WORD_MASK(size);
-               unsigned long idx = (size-1) / BITS_PER_LONG;
+               unsigned long idx = (size - 1) / BITS_PER_LONG;

                do {
                        val &= addr[idx];
@@ -156,6 +239,27 @@ unsigned long find_last_bit(const unsigned long
*addr, unsigned long size)
 EXPORT_SYMBOL(find_last_bit);
 #endif

+#ifndef find_last_zero_bit
+unsigned long find_last_zero_bit(const unsigned long *addr, unsigned long size)
+{
+       if (size) {
+               unsigned long val = BITMAP_LAST_WORD_MASK(size);
+               unsigned long idx = (size - 1) / BITS_PER_LONG;
+
+               do {
+                       val &= ~addr[idx];
+                       if (val)
+                               return idx * BITS_PER_LONG + __fls(val);
+
+                       val = ~0ul;
+               } while (idx--);
+       }
+
+       return size;
+}
+EXPORT_SYMBOL(find_last_zero_bit);
+#endif
+
 #ifdef __BIG_ENDIAN

 #ifndef find_next_zero_bit_le
@@ -167,6 +271,15 @@ unsigned long find_next_zero_bit_le(const void
*addr, unsigned
 EXPORT_SYMBOL(find_next_zero_bit_le);
 #endif

+#ifndef find_prev_zero_bit_le
+unsigned long find_prev_zero_bit_le(const void *addr, unsigned
+               long size, unsigned long offset)
+{
+       return _find_prev_bit(addr, NULL, size, offset, ~0UL, 1);
+}
+EXPORT_SYMBOL(find_prev_zero_bit_le);
+#endif
+
 #ifndef find_next_bit_le
 unsigned long find_next_bit_le(const void *addr, unsigned
                long size, unsigned long offset)
@@ -176,6 +289,15 @@ unsigned long find_next_bit_le(const void *addr, unsigned
 EXPORT_SYMBOL(find_next_bit_le);
 #endif

+#ifdef find_prev_bit_le
+unsigned long find_prev_bit_le(const void *addr, unsigned
+               long size, unsigned long offset)
+{
+       return _find_prev_bit(addr, NULL, size, offset, 0UL, 1);
+}
+EXPORT_SYMBOL(find_prev_bit_le);
+#endif
+
 #endif /* __BIG_ENDIAN */

 unsigned long find_next_clump8(unsigned long *clump, const unsigned long *addr,
--
2.29.2

^ permalink raw reply related	[flat|nested] 414+ messages in thread
* Re: [PATCH v4] arm64: dts: qcom: Add support for Xiaomi Poco F1 (Beryllium)
@ 2020-08-05 11:02 Amit Pundir
  2020-08-06 22:31 ` Konrad Dybcio
  0 siblings, 1 reply; 414+ messages in thread
From: Amit Pundir @ 2020-08-05 11:02 UTC (permalink / raw)
  To: Andy Gross, Bjorn Andersson, Rob Herring, John Stultz, Sumit Semwal
  Cc: linux-arm-msm, dt, lkml

On Wed, 5 Aug 2020 at 16:21, Amit Pundir <amit.pundir@linaro.org> wrote:
>
> Add initial dts support for Xiaomi Poco F1 (Beryllium).
>
> This initial support is based on upstream Dragonboard 845c
> (sdm845) device. With this dts, Beryllium boots AOSP up to
> ADB shell over USB-C.
>
> Supported functionality includes UFS, USB-C (peripheral),
> microSD card and Vol+/Vol-/power keys. Bluetooth should work
> too but couldn't be verified from adb command line, it is
> verified when enabled from UI with few WIP display patches.
>
> Just like initial db845c support, initializing the SMMU is
> clearing the mapping used for the splash screen framebuffer,
> which causes the device to hang during boot and recovery
> needs a hard power reset. This can be worked around using:
>
>     fastboot oem select-display-panel none
>
> To switch ON the display back run:
>
>     fastboot oem select-display-panel
>
> But this only works on Beryllium devices running bootloader
> version BOOT.XF.2.0-00369-SDM845LZB-1 that shipped with
> Android-9 based release. Newer bootloader version do not
> support switching OFF the display panel at all. So we need
> a few additional smmu patches (under review) from here to
> boot to shell:
> https://github.com/pundiramit/linux/commits/beryllium-mainline
>
> Signed-off-by: Amit Pundir <amit.pundir@linaro.org>
> ---
> v4: Added more downstream reserved memory regions. It probably
>     need more work, but for now I see adsp/cdsp/wlan remoteprocs
>     powering up properly. Also removed the regulator nodes not
>     required for the device, as suggested by Bjorn.

Forgot to mention that I added couple of clocks to protected clocks in v4,
which need for display to work.

> v3: Added a reserved-memory region from downstream kernel to fix
>     a boot regression with recent dma-pool changes in v5.8-rc6.
> v2: Updated machine compatible string for seemingly inevitable
>     future quirks.
>
>  arch/arm64/boot/dts/qcom/Makefile             |   1 +
>  arch/arm64/boot/dts/qcom/sdm845-beryllium.dts | 383 ++++++++++++++++++++++++++
>  2 files changed, 384 insertions(+)
>  create mode 100644 arch/arm64/boot/dts/qcom/sdm845-beryllium.dts
>
> diff --git a/arch/arm64/boot/dts/qcom/Makefile b/arch/arm64/boot/dts/qcom/Makefile
> index 0f2c33d611df..3ef1b48bc0cb 100644
> --- a/arch/arm64/boot/dts/qcom/Makefile
> +++ b/arch/arm64/boot/dts/qcom/Makefile
> @@ -21,6 +21,7 @@ dtb-$(CONFIG_ARCH_QCOM)       += sdm845-cheza-r1.dtb
>  dtb-$(CONFIG_ARCH_QCOM)        += sdm845-cheza-r2.dtb
>  dtb-$(CONFIG_ARCH_QCOM)        += sdm845-cheza-r3.dtb
>  dtb-$(CONFIG_ARCH_QCOM)        += sdm845-db845c.dtb
> +dtb-$(CONFIG_ARCH_QCOM)        += sdm845-beryllium.dtb
>  dtb-$(CONFIG_ARCH_QCOM)        += sdm845-mtp.dtb
>  dtb-$(CONFIG_ARCH_QCOM)        += sdm850-lenovo-yoga-c630.dtb
>  dtb-$(CONFIG_ARCH_QCOM)        += sm8150-mtp.dtb
> diff --git a/arch/arm64/boot/dts/qcom/sdm845-beryllium.dts b/arch/arm64/boot/dts/qcom/sdm845-beryllium.dts
> new file mode 100644
> index 000000000000..0f9f61bf9fa4
> --- /dev/null
> +++ b/arch/arm64/boot/dts/qcom/sdm845-beryllium.dts
> @@ -0,0 +1,383 @@
> +// SPDX-License-Identifier: GPL-2.0
> +
> +/dts-v1/;
> +
> +#include <dt-bindings/gpio/gpio.h>
> +#include <dt-bindings/pinctrl/qcom,pmic-gpio.h>
> +#include <dt-bindings/regulator/qcom,rpmh-regulator.h>
> +#include "sdm845.dtsi"
> +#include "pm8998.dtsi"
> +#include "pmi8998.dtsi"
> +
> +/ {
> +       model = "Xiaomi Technologies Inc. Beryllium";
> +       compatible = "xiaomi,beryllium", "qcom,sdm845";
> +
> +       /* required for bootloader to select correct board */
> +       qcom,board-id = <69 0>;
> +       qcom,msm-id = <321 0x20001>;
> +
> +       aliases {
> +               hsuart0 = &uart6;
> +       };
> +
> +       gpio-keys {
> +               compatible = "gpio-keys";
> +               autorepeat;
> +
> +               pinctrl-names = "default";
> +               pinctrl-0 = <&vol_up_pin_a>;
> +
> +               vol-up {
> +                       label = "Volume Up";
> +                       linux,code = <KEY_VOLUMEUP>;
> +                       gpios = <&pm8998_gpio 6 GPIO_ACTIVE_LOW>;
> +               };
> +       };
> +
> +       vreg_s4a_1p8: vreg-s4a-1p8 {
> +               compatible = "regulator-fixed";
> +               regulator-name = "vreg_s4a_1p8";
> +
> +               regulator-min-microvolt = <1800000>;
> +               regulator-max-microvolt = <1800000>;
> +               regulator-always-on;
> +       };
> +};
> +
> +&adsp_pas {
> +       status = "okay";
> +       firmware-name = "qcom/sdm845/adsp.mdt";
> +};
> +
> +&apps_rsc {
> +       pm8998-rpmh-regulators {
> +               compatible = "qcom,pm8998-rpmh-regulators";
> +               qcom,pmic-id = "a";
> +
> +               vreg_l1a_0p875: ldo1 {
> +                       regulator-min-microvolt = <880000>;
> +                       regulator-max-microvolt = <880000>;
> +                       regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
> +               };
> +
> +               vreg_l5a_0p8: ldo5 {
> +                       regulator-min-microvolt = <800000>;
> +                       regulator-max-microvolt = <800000>;
> +                       regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
> +               };
> +
> +               vreg_l7a_1p8: ldo7 {
> +                       regulator-min-microvolt = <1800000>;
> +                       regulator-max-microvolt = <1800000>;
> +                       regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
> +               };
> +
> +               vreg_l12a_1p8: ldo12 {
> +                       regulator-min-microvolt = <1800000>;
> +                       regulator-max-microvolt = <1800000>;
> +                       regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
> +               };
> +
> +               vreg_l13a_2p95: ldo13 {
> +                       regulator-min-microvolt = <1800000>;
> +                       regulator-max-microvolt = <2960000>;
> +                       regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
> +               };
> +
> +               vreg_l17a_1p3: ldo17 {
> +                       regulator-min-microvolt = <1304000>;
> +                       regulator-max-microvolt = <1304000>;
> +                       regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
> +               };
> +
> +               vreg_l20a_2p95: ldo20 {
> +                       regulator-min-microvolt = <2960000>;
> +                       regulator-max-microvolt = <2968000>;
> +                       regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
> +               };
> +
> +               vreg_l21a_2p95: ldo21 {
> +                       regulator-min-microvolt = <2960000>;
> +                       regulator-max-microvolt = <2968000>;
> +                       regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
> +               };
> +
> +               vreg_l24a_3p075: ldo24 {
> +                       regulator-min-microvolt = <3088000>;
> +                       regulator-max-microvolt = <3088000>;
> +                       regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
> +               };
> +
> +               vreg_l25a_3p3: ldo25 {
> +                       regulator-min-microvolt = <3300000>;
> +                       regulator-max-microvolt = <3312000>;
> +                       regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
> +               };
> +
> +               vreg_l26a_1p2: ldo26 {
> +                       regulator-min-microvolt = <1200000>;
> +                       regulator-max-microvolt = <1200000>;
> +                       regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
> +               };
> +       };
> +};
> +
> +&cdsp_pas {
> +       status = "okay";
> +       firmware-name = "qcom/sdm845/cdsp.mdt";
> +};
> +
> +&gcc {
> +       protected-clocks = <GCC_QSPI_CORE_CLK>,
> +                          <GCC_QSPI_CORE_CLK_SRC>,
> +                          <GCC_QSPI_CNOC_PERIPH_AHB_CLK>,
> +                          <GCC_LPASS_Q6_AXI_CLK>,
> +                          <GCC_LPASS_SWAY_CLK>;
> +};
> +
> +&gpu {
> +       zap-shader {
> +               memory-region = <&gpu_mem>;
> +               firmware-name = "qcom/sdm845/a630_zap.mbn";
> +       };
> +};
> +
> +/* Reserved memory changes from downstream */
> +/delete-node/ &adsp_mem;
> +/delete-node/ &wlan_msa_mem;
> +/delete-node/ &mpss_region;
> +/delete-node/ &venus_mem;
> +/delete-node/ &cdsp_mem;
> +/delete-node/ &mba_region;
> +/delete-node/ &slpi_mem;
> +/delete-node/ &spss_mem;
> +/delete-node/ &rmtfs_mem;
> +/ {
> +       reserved-memory {
> +               // This removed_region is needed to boot the device
> +               // TODO: Find out the user of this reserved memory
> +               removed_region: memory@88f00000 {
> +                       reg = <0 0x88f00000 0 0x1a00000>;
> +                       no-map;
> +               };
> +
> +               adsp_mem: memory@8c500000 {
> +                       reg = <0 0x8c500000 0 0x1e00000>;
> +                       no-map;
> +               };
> +
> +               wlan_msa_mem: memory@8e300000 {
> +                       reg = <0 0x8e300000 0 0x100000>;
> +                       no-map;
> +               };
> +
> +               mpss_region: memory@8e400000 {
> +                       reg = <0 0x8e400000 0 0x7800000>;
> +                       no-map;
> +               };
> +
> +               venus_mem: memory@95c00000 {
> +                       reg = <0 0x95c00000 0 0x500000>;
> +                       no-map;
> +               };
> +
> +               cdsp_mem: memory@96100000 {
> +                       reg = <0 0x96100000 0 0x800000>;
> +                       no-map;
> +               };
> +
> +               mba_region: memory@96900000 {
> +                       reg = <0 0x96900000 0 0x200000>;
> +                       no-map;
> +               };
> +
> +               slpi_mem: memory@96b00000 {
> +                       reg = <0 0x96b00000 0 0x1400000>;
> +                       no-map;
> +               };
> +
> +               spss_mem: memory@97f00000 {
> +                       reg = <0 0x97f00000 0 0x100000>;
> +                       no-map;
> +               };
> +
> +               rmtfs_mem: memory@f6301000 {
> +                       compatible = "qcom,rmtfs-mem";
> +                       reg = <0 0xf6301000 0 0x200000>;
> +                       no-map;
> +
> +                       qcom,client-id = <1>;
> +                       qcom,vmid = <15>;
> +               };
> +       };
> +};
> +
> +&mss_pil {
> +       status = "okay";
> +       firmware-name = "qcom/sdm845/mba.mbn", "qcom/sdm845/modem.mdt";
> +};
> +
> +&pm8998_gpio {
> +       vol_up_pin_a: vol-up-active {
> +               pins = "gpio6";
> +               function = "normal";
> +               input-enable;
> +               bias-pull-up;
> +               qcom,drive-strength = <PMIC_GPIO_STRENGTH_NO>;
> +       };
> +};
> +
> +&pm8998_pon {
> +       resin {
> +               compatible = "qcom,pm8941-resin";
> +               interrupts = <0x0 0x8 1 IRQ_TYPE_EDGE_BOTH>;
> +               debounce = <15625>;
> +               bias-pull-up;
> +               linux,code = <KEY_VOLUMEDOWN>;
> +       };
> +};
> +
> +&qupv3_id_0 {
> +       status = "okay";
> +};
> +
> +&sdhc_2 {
> +       status = "okay";
> +
> +       pinctrl-names = "default";
> +       pinctrl-0 = <&sdc2_default_state &sdc2_card_det_n>;
> +
> +       vmmc-supply = <&vreg_l21a_2p95>;
> +       vqmmc-supply = <&vreg_l13a_2p95>;
> +
> +       bus-width = <4>;
> +       cd-gpios = <&tlmm 126 GPIO_ACTIVE_HIGH>;
> +};
> +
> +&tlmm {
> +       gpio-reserved-ranges = <0 4>, <81 4>;
> +
> +       sdc2_default_state: sdc2-default {
> +               clk {
> +                       pins = "sdc2_clk";
> +                       bias-disable;
> +
> +                       /*
> +                        * It seems that mmc_test reports errors if drive
> +                        * strength is not 16 on clk, cmd, and data pins.
> +                        */
> +                       drive-strength = <16>;
> +               };
> +
> +               cmd {
> +                       pins = "sdc2_cmd";
> +                       bias-pull-up;
> +                       drive-strength = <10>;
> +               };
> +
> +               data {
> +                       pins = "sdc2_data";
> +                       bias-pull-up;
> +                       drive-strength = <10>;
> +               };
> +       };
> +
> +       sdc2_card_det_n: sd-card-det-n {
> +               pins = "gpio126";
> +               function = "gpio";
> +               bias-pull-up;
> +       };
> +};
> +
> +&uart6 {
> +       status = "okay";
> +
> +       bluetooth {
> +               compatible = "qcom,wcn3990-bt";
> +
> +               vddio-supply = <&vreg_s4a_1p8>;
> +               vddxo-supply = <&vreg_l7a_1p8>;
> +               vddrf-supply = <&vreg_l17a_1p3>;
> +               vddch0-supply = <&vreg_l25a_3p3>;
> +               max-speed = <3200000>;
> +       };
> +};
> +
> +&usb_1 {
> +       status = "okay";
> +};
> +
> +&usb_1_dwc3 {
> +       dr_mode = "peripheral";
> +};
> +
> +&usb_1_hsphy {
> +       status = "okay";
> +
> +       vdd-supply = <&vreg_l1a_0p875>;
> +       vdda-pll-supply = <&vreg_l12a_1p8>;
> +       vdda-phy-dpdm-supply = <&vreg_l24a_3p075>;
> +
> +       qcom,imp-res-offset-value = <8>;
> +       qcom,hstx-trim-value = <QUSB2_V2_HSTX_TRIM_21_6_MA>;
> +       qcom,preemphasis-level = <QUSB2_V2_PREEMPHASIS_5_PERCENT>;
> +       qcom,preemphasis-width = <QUSB2_V2_PREEMPHASIS_WIDTH_HALF_BIT>;
> +};
> +
> +&usb_1_qmpphy {
> +       status = "okay";
> +
> +       vdda-phy-supply = <&vreg_l26a_1p2>;
> +       vdda-pll-supply = <&vreg_l1a_0p875>;
> +};
> +
> +&ufs_mem_hc {
> +       status = "okay";
> +
> +       reset-gpios = <&tlmm 150 GPIO_ACTIVE_LOW>;
> +
> +       vcc-supply = <&vreg_l20a_2p95>;
> +       vcc-max-microamp = <800000>;
> +};
> +
> +&ufs_mem_phy {
> +       status = "okay";
> +
> +       vdda-phy-supply = <&vreg_l1a_0p875>;
> +       vdda-pll-supply = <&vreg_l26a_1p2>;
> +};
> +
> +&wifi {
> +       status = "okay";
> +
> +       vdd-0.8-cx-mx-supply = <&vreg_l5a_0p8>;
> +       vdd-1.8-xo-supply = <&vreg_l7a_1p8>;
> +       vdd-1.3-rfa-supply = <&vreg_l17a_1p3>;
> +       vdd-3.3-ch0-supply = <&vreg_l25a_3p3>;
> +};
> +
> +/* PINCTRL - additions to nodes defined in sdm845.dtsi */
> +
> +&qup_uart6_default {
> +       pinmux {
> +               pins = "gpio45", "gpio46", "gpio47", "gpio48";
> +               function = "qup6";
> +       };
> +
> +       cts {
> +               pins = "gpio45";
> +               bias-disable;
> +       };
> +
> +       rts-tx {
> +               pins = "gpio46", "gpio47";
> +               drive-strength = <2>;
> +               bias-disable;
> +       };
> +
> +       rx {
> +               pins = "gpio48";
> +               bias-pull-up;
> +       };
> +};
> --
> 2.7.4
>

^ permalink raw reply	[flat|nested] 414+ messages in thread
* (no subject)
@ 2020-06-30 17:56 Vasiliy Kupriakov
  2020-07-10 20:36 ` Andy Shevchenko
  0 siblings, 1 reply; 414+ messages in thread
From: Vasiliy Kupriakov @ 2020-06-30 17:56 UTC (permalink / raw)
  To: Corentin Chary, Darren Hart, Andy Shevchenko
  Cc: Vasiliy Kupriakov,
	open list:ASUS NOTEBOOKS AND EEEPC ACPI/WMI EXTRAS DRIVERS,
	open list:ASUS NOTEBOOKS AND EEEPC ACPI/WMI EXTRAS DRIVERS,
	open list

Subject: [PATCH] platform/x86: asus-wmi: allow BAT1 battery name

The battery on my laptop ASUS TUF Gaming FX706II is named BAT1.
This patch allows battery extension to load.

Signed-off-by: Vasiliy Kupriakov <rublag-ns@yandex.ru>
---
 drivers/platform/x86/asus-wmi.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/platform/x86/asus-wmi.c b/drivers/platform/x86/asus-wmi.c
index 877aade19497..8f4acdc06b13 100644
--- a/drivers/platform/x86/asus-wmi.c
+++ b/drivers/platform/x86/asus-wmi.c
@@ -441,6 +441,7 @@ static int asus_wmi_battery_add(struct power_supply *battery)
 	 * battery is named BATT.
 	 */
 	if (strcmp(battery->desc->name, "BAT0") != 0 &&
+	    strcmp(battery->desc->name, "BAT1") != 0 &&
 	    strcmp(battery->desc->name, "BATT") != 0)
 		return -ENODEV;
 
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 414+ messages in thread
* (no subject)
@ 2020-05-06  5:52 Jiaxun Yang
  2020-05-06 17:17 ` Nick Desaulniers
  0 siblings, 1 reply; 414+ messages in thread
From: Jiaxun Yang @ 2020-05-06  5:52 UTC (permalink / raw)
  To: linux-mips
  Cc: Jiaxun Yang, clang-built-linux, Maciej W . Rozycki, Fangrui Song,
	Kees Cook, Nathan Chancellor, Thomas Bogendoerfer, Paul Burton,
	Masahiro Yamada, Jouni Hogander, Kevin Darbyshire-Bryant,
	Borislav Petkov, Heiko Carstens, linux-kernel

Subject: [PATCH v6] MIPS: Truncate link address into 32bit for 32bit kernel
In-Reply-To: <20200413062651.3992652-1-jiaxun.yang@flygoat.com>

LLD failed to link vmlinux with 64bit load address for 32bit ELF
while bfd will strip 64bit address into 32bit silently.
To fix LLD build, we should truncate load address provided by platform
into 32bit for 32bit kernel.

Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com>
Link: https://github.com/ClangBuiltLinux/linux/issues/786
Link: https://sourceware.org/bugzilla/show_bug.cgi?id=25784
Reviewed-by: Fangrui Song <maskray@google.com>
Reviewed-by: Kees Cook <keescook@chromium.org>
Tested-by: Nathan Chancellor <natechancellor@gmail.com>
Cc: Maciej W. Rozycki <macro@linux-mips.org>
---
V2: Take MaskRay's shell magic.

V3: After spent an hour on dealing with special character issue in
Makefile, I gave up to do shell hacks and write a util in C instead.
Thanks Maciej for pointing out Makefile variable problem.

v4: Finally we managed to find a Makefile method to do it properly
thanks to Kees. As it's too far from the initial version, I removed
Review & Test tag from Nick and Fangrui and Cc instead.

v5: Care vmlinuz as well.

v6: Rename to LIKER_LOAD_ADDRESS 
---
 arch/mips/Makefile                 | 13 ++++++++++++-
 arch/mips/boot/compressed/Makefile |  2 +-
 arch/mips/kernel/vmlinux.lds.S     |  2 +-
 3 files changed, 14 insertions(+), 3 deletions(-)

diff --git a/arch/mips/Makefile b/arch/mips/Makefile
index e1c44aed8156..68c0f22fefc0 100644
--- a/arch/mips/Makefile
+++ b/arch/mips/Makefile
@@ -288,12 +288,23 @@ ifdef CONFIG_64BIT
   endif
 endif
 
+# When linking a 32-bit executable the LLVM linker cannot cope with a
+# 32-bit load address that has been sign-extended to 64 bits.  Simply
+# remove the upper 32 bits then, as it is safe to do so with other
+# linkers.
+ifdef CONFIG_64BIT
+	load-ld			= $(load-y)
+else
+	load-ld			= $(subst 0xffffffff,0x,$(load-y))
+endif
+
 KBUILD_AFLAGS	+= $(cflags-y)
 KBUILD_CFLAGS	+= $(cflags-y)
-KBUILD_CPPFLAGS += -DVMLINUX_LOAD_ADDRESS=$(load-y)
+KBUILD_CPPFLAGS += -DVMLINUX_LOAD_ADDRESS=$(load-y) -DLINKER_LOAD_ADDRESS=$(load-ld)
 KBUILD_CPPFLAGS += -DDATAOFFSET=$(if $(dataoffset-y),$(dataoffset-y),0)
 
 bootvars-y	= VMLINUX_LOAD_ADDRESS=$(load-y) \
+		  LINKER_LOAD_ADDRESS=$(load-ld) \
 		  VMLINUX_ENTRY_ADDRESS=$(entry-y) \
 		  PLATFORM="$(platform-y)" \
 		  ITS_INPUTS="$(its-y)"
diff --git a/arch/mips/boot/compressed/Makefile b/arch/mips/boot/compressed/Makefile
index 0df0ee8a298d..3d391256ab7e 100644
--- a/arch/mips/boot/compressed/Makefile
+++ b/arch/mips/boot/compressed/Makefile
@@ -90,7 +90,7 @@ ifneq ($(zload-y),)
 VMLINUZ_LOAD_ADDRESS := $(zload-y)
 else
 VMLINUZ_LOAD_ADDRESS = $(shell $(obj)/calc_vmlinuz_load_addr \
-		$(obj)/vmlinux.bin $(VMLINUX_LOAD_ADDRESS))
+		$(obj)/vmlinux.bin $(LINKER_LOAD_ADDRESS))
 endif
 UIMAGE_LOADADDR = $(VMLINUZ_LOAD_ADDRESS)
 
diff --git a/arch/mips/kernel/vmlinux.lds.S b/arch/mips/kernel/vmlinux.lds.S
index a5f00ec73ea6..5226cd8e4bee 100644
--- a/arch/mips/kernel/vmlinux.lds.S
+++ b/arch/mips/kernel/vmlinux.lds.S
@@ -55,7 +55,7 @@ SECTIONS
 	/* . = 0xa800000000300000; */
 	. = 0xffffffff80300000;
 #endif
-	. = VMLINUX_LOAD_ADDRESS;
+	. = LINKER_LOAD_ADDRESS;
 	/* read-only */
 	_text = .;	/* Text and read-only data */
 	.text : {

^ permalink raw reply related	[flat|nested] 414+ messages in thread
[parent not found: <5e7dc543.vYG3wru8B/me1sOV%chenanqing@oppo.com>]
[parent not found: <5e7dbb10.ulraq/ljeOm297+z%chenanqing@oppo.com>]
* (no subject)
@ 2020-03-03 15:27 Gene Chen
  2020-03-04 14:56 ` Matthias Brugger
  0 siblings, 1 reply; 414+ messages in thread
From: Gene Chen @ 2020-03-03 15:27 UTC (permalink / raw)
  To: lee.jones, matthias.bgg
  Cc: linux-arm-kernel, linux-mediatek, linux-kernel, gene_chen,
	Wilma.Wu, shufan_lee, cy_huang


Add mfd driver for mt6360 pmic chip include
Battery Charger/USB_PD/Flash LED/RGB LED/LDO/Buck

Signed-off-by: Gene Chen <gene_chen@richtek.com
---
 drivers/mfd/Kconfig        |  12 ++
 drivers/mfd/Makefile       |   1 +
 drivers/mfd/mt6360-core.c  | 425 +++++++++++++++++++++++++++++++++++++++++++++
 include/linux/mfd/mt6360.h | 240 +++++++++++++++++++++++++
 4 files changed, 678 insertions(+)
 create mode 100644 drivers/mfd/mt6360-core.c
 create mode 100644 include/linux/mfd/mt6360.h

changelogs between v1 & v2
- include missing header file

changelogs between v2 & v3
- add changelogs

changelogs between v3 & v4
- fix Kconfig description
- replace mt6360_pmu_info with mt6360_pmu_data
- replace probe with probe_new
- remove unnecessary irq_chip variable
- remove annotation
- replace MT6360_MFD_CELL with OF_MFD_CELL

changelogs between v4 & v5
- remove unnecessary parse dt function
- use devm_i2c_new_dummy_device
- add base-commit message

changelogs between v5 & v6
- review return value
- remove i2c id_table
- use GPL license v2

changelogs between v6 & v7
- add author description
- replace MT6360_REGMAP_IRQ_REG by REGMAP_IRQ_REG_LINE
- remove mt6360-private.h

changelogs between v7 & v8
- fix kbuild auto reboot by include interrupt header

diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 2b20329..0f8c341 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -857,6 +857,18 @@ config MFD_MAX8998
 	  additional drivers must be enabled in order to use the functionality
 	  of the device.
 
+config MFD_MT6360
+	tristate "Mediatek MT6360 SubPMIC"
+	select MFD_CORE
+	select REGMAP_I2C
+	select REGMAP_IRQ
+	depends on I2C
+	help
+	  Say Y here to enable MT6360 PMU/PMIC/LDO functional support.
+	  PMU part includes Charger, Flashlight, RGB LED
+	  PMIC part includes 2-channel BUCKs and 2-channel LDOs
+	  LDO part includes 4-channel LDOs
+
 config MFD_MT6397
 	tristate "MediaTek MT6397 PMIC Support"
 	select MFD_CORE
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index b83f172..8c35816 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -238,6 +238,7 @@ obj-$(CONFIG_INTEL_SOC_PMIC)	+= intel-soc-pmic.o
 obj-$(CONFIG_INTEL_SOC_PMIC_BXTWC)	+= intel_soc_pmic_bxtwc.o
 obj-$(CONFIG_INTEL_SOC_PMIC_CHTWC)	+= intel_soc_pmic_chtwc.o
 obj-$(CONFIG_INTEL_SOC_PMIC_CHTDC_TI)	+= intel_soc_pmic_chtdc_ti.o
+obj-$(CONFIG_MFD_MT6360)	+= mt6360-core.o
 mt6397-objs	:= mt6397-core.o mt6397-irq.o
 obj-$(CONFIG_MFD_MT6397)	+= mt6397.o
 obj-$(CONFIG_INTEL_SOC_PMIC_MRFLD)	+= intel_soc_pmic_mrfld.o
diff --git a/drivers/mfd/mt6360-core.c b/drivers/mfd/mt6360-core.c
new file mode 100644
index 0000000..d1168f8
--- /dev/null
+++ b/drivers/mfd/mt6360-core.c
@@ -0,0 +1,425 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2019 MediaTek Inc.
+ *
+ * Author: Gene Chen <gene_chen@richtek.com>
+ */
+
+#include <linux/i2c.h>
+#include <linux/init.h>
+#include <linux/interrupt.h>
+#include <linux/kernel.h>
+#include <linux/mfd/core.h>
+#include <linux/module.h>
+#include <linux/of_irq.h>
+#include <linux/of_platform.h>
+#include <linux/version.h>
+
+#include <linux/mfd/mt6360.h>
+
+/* reg 0 -> 0 ~ 7 */
+#define MT6360_CHG_TREG_EVT		(4)
+#define MT6360_CHG_AICR_EVT		(5)
+#define MT6360_CHG_MIVR_EVT		(6)
+#define MT6360_PWR_RDY_EVT		(7)
+/* REG 1 -> 8 ~ 15 */
+#define MT6360_CHG_BATSYSUV_EVT		(9)
+#define MT6360_FLED_CHG_VINOVP_EVT	(11)
+#define MT6360_CHG_VSYSUV_EVT		(12)
+#define MT6360_CHG_VSYSOV_EVT		(13)
+#define MT6360_CHG_VBATOV_EVT		(14)
+#define MT6360_CHG_VBUSOV_EVT		(15)
+/* REG 2 -> 16 ~ 23 */
+/* REG 3 -> 24 ~ 31 */
+#define MT6360_WD_PMU_DET		(25)
+#define MT6360_WD_PMU_DONE		(26)
+#define MT6360_CHG_TMRI			(27)
+#define MT6360_CHG_ADPBADI		(29)
+#define MT6360_CHG_RVPI			(30)
+#define MT6360_OTPI			(31)
+/* REG 4 -> 32 ~ 39 */
+#define MT6360_CHG_AICCMEASL		(32)
+#define MT6360_CHGDET_DONEI		(34)
+#define MT6360_WDTMRI			(35)
+#define MT6360_SSFINISHI		(36)
+#define MT6360_CHG_RECHGI		(37)
+#define MT6360_CHG_TERMI		(38)
+#define MT6360_CHG_IEOCI		(39)
+/* REG 5 -> 40 ~ 47 */
+#define MT6360_PUMPX_DONEI		(40)
+#define MT6360_BAT_OVP_ADC_EVT		(41)
+#define MT6360_TYPEC_OTP_EVT		(42)
+#define MT6360_ADC_WAKEUP_EVT		(43)
+#define MT6360_ADC_DONEI		(44)
+#define MT6360_BST_BATUVI		(45)
+#define MT6360_BST_VBUSOVI		(46)
+#define MT6360_BST_OLPI			(47)
+/* REG 6 -> 48 ~ 55 */
+#define MT6360_ATTACH_I			(48)
+#define MT6360_DETACH_I			(49)
+#define MT6360_QC30_STPDONE		(51)
+#define MT6360_QC_VBUSDET_DONE		(52)
+#define MT6360_HVDCP_DET		(53)
+#define MT6360_CHGDETI			(54)
+#define MT6360_DCDTI			(55)
+/* REG 7 -> 56 ~ 63 */
+#define MT6360_FOD_DONE_EVT		(56)
+#define MT6360_FOD_OV_EVT		(57)
+#define MT6360_CHRDET_UVP_EVT		(58)
+#define MT6360_CHRDET_OVP_EVT		(59)
+#define MT6360_CHRDET_EXT_EVT		(60)
+#define MT6360_FOD_LR_EVT		(61)
+#define MT6360_FOD_HR_EVT		(62)
+#define MT6360_FOD_DISCHG_FAIL_EVT	(63)
+/* REG 8 -> 64 ~ 71 */
+#define MT6360_USBID_EVT		(64)
+#define MT6360_APWDTRST_EVT		(65)
+#define MT6360_EN_EVT			(66)
+#define MT6360_QONB_RST_EVT		(67)
+#define MT6360_MRSTB_EVT		(68)
+#define MT6360_OTP_EVT			(69)
+#define MT6360_VDDAOV_EVT		(70)
+#define MT6360_SYSUV_EVT		(71)
+/* REG 9 -> 72 ~ 79 */
+#define MT6360_FLED_STRBPIN_EVT		(72)
+#define MT6360_FLED_TORPIN_EVT		(73)
+#define MT6360_FLED_TX_EVT		(74)
+#define MT6360_FLED_LVF_EVT		(75)
+#define MT6360_FLED2_SHORT_EVT		(78)
+#define MT6360_FLED1_SHORT_EVT		(79)
+/* REG 10 -> 80 ~ 87 */
+#define MT6360_FLED2_STRB_EVT		(80)
+#define MT6360_FLED1_STRB_EVT		(81)
+#define MT6360_FLED2_STRB_TO_EVT	(82)
+#define MT6360_FLED1_STRB_TO_EVT	(83)
+#define MT6360_FLED2_TOR_EVT		(84)
+#define MT6360_FLED1_TOR_EVT		(85)
+/* REG 11 -> 88 ~ 95 */
+/* REG 12 -> 96 ~ 103 */
+#define MT6360_BUCK1_PGB_EVT		(96)
+#define MT6360_BUCK1_OC_EVT		(100)
+#define MT6360_BUCK1_OV_EVT		(101)
+#define MT6360_BUCK1_UV_EVT		(102)
+/* REG 13 -> 104 ~ 111 */
+#define MT6360_BUCK2_PGB_EVT		(104)
+#define MT6360_BUCK2_OC_EVT		(108)
+#define MT6360_BUCK2_OV_EVT		(109)
+#define MT6360_BUCK2_UV_EVT		(110)
+/* REG 14 -> 112 ~ 119 */
+#define MT6360_LDO1_OC_EVT		(113)
+#define MT6360_LDO2_OC_EVT		(114)
+#define MT6360_LDO3_OC_EVT		(115)
+#define MT6360_LDO5_OC_EVT		(117)
+#define MT6360_LDO6_OC_EVT		(118)
+#define MT6360_LDO7_OC_EVT		(119)
+/* REG 15 -> 120 ~ 127 */
+#define MT6360_LDO1_PGB_EVT		(121)
+#define MT6360_LDO2_PGB_EVT		(122)
+#define MT6360_LDO3_PGB_EVT		(123)
+#define MT6360_LDO5_PGB_EVT		(125)
+#define MT6360_LDO6_PGB_EVT		(126)
+#define MT6360_LDO7_PGB_EVT		(127)
+
+static const struct regmap_irq mt6360_pmu_irqs[] =  {
+	REGMAP_IRQ_REG_LINE(MT6360_CHG_TREG_EVT, 8),
+	REGMAP_IRQ_REG_LINE(MT6360_CHG_AICR_EVT, 8),
+	REGMAP_IRQ_REG_LINE(MT6360_CHG_MIVR_EVT, 8),
+	REGMAP_IRQ_REG_LINE(MT6360_PWR_RDY_EVT, 8),
+	REGMAP_IRQ_REG_LINE(MT6360_CHG_BATSYSUV_EVT, 8),
+	REGMAP_IRQ_REG_LINE(MT6360_FLED_CHG_VINOVP_EVT, 8),
+	REGMAP_IRQ_REG_LINE(MT6360_CHG_VSYSUV_EVT, 8),
+	REGMAP_IRQ_REG_LINE(MT6360_CHG_VSYSOV_EVT, 8),
+	REGMAP_IRQ_REG_LINE(MT6360_CHG_VBATOV_EVT, 8),
+	REGMAP_IRQ_REG_LINE(MT6360_CHG_VBUSOV_EVT, 8),
+	REGMAP_IRQ_REG_LINE(MT6360_WD_PMU_DET, 8),
+	REGMAP_IRQ_REG_LINE(MT6360_WD_PMU_DONE, 8),
+	REGMAP_IRQ_REG_LINE(MT6360_CHG_TMRI, 8),
+	REGMAP_IRQ_REG_LINE(MT6360_CHG_ADPBADI, 8),
+	REGMAP_IRQ_REG_LINE(MT6360_CHG_RVPI, 8),
+	REGMAP_IRQ_REG_LINE(MT6360_OTPI, 8),
+	REGMAP_IRQ_REG_LINE(MT6360_CHG_AICCMEASL, 8),
+	REGMAP_IRQ_REG_LINE(MT6360_CHGDET_DONEI, 8),
+	REGMAP_IRQ_REG_LINE(MT6360_WDTMRI, 8),
+	REGMAP_IRQ_REG_LINE(MT6360_SSFINISHI, 8),
+	REGMAP_IRQ_REG_LINE(MT6360_CHG_RECHGI, 8),
+	REGMAP_IRQ_REG_LINE(MT6360_CHG_TERMI, 8),
+	REGMAP_IRQ_REG_LINE(MT6360_CHG_IEOCI, 8),
+	REGMAP_IRQ_REG_LINE(MT6360_PUMPX_DONEI, 8),
+	REGMAP_IRQ_REG_LINE(MT6360_CHG_TREG_EVT, 8),
+	REGMAP_IRQ_REG_LINE(MT6360_BAT_OVP_ADC_EVT, 8),
+	REGMAP_IRQ_REG_LINE(MT6360_TYPEC_OTP_EVT, 8),
+	REGMAP_IRQ_REG_LINE(MT6360_ADC_WAKEUP_EVT, 8),
+	REGMAP_IRQ_REG_LINE(MT6360_ADC_DONEI, 8),
+	REGMAP_IRQ_REG_LINE(MT6360_BST_BATUVI, 8),
+	REGMAP_IRQ_REG_LINE(MT6360_BST_VBUSOVI, 8),
+	REGMAP_IRQ_REG_LINE(MT6360_BST_OLPI, 8),
+	REGMAP_IRQ_REG_LINE(MT6360_ATTACH_I, 8),
+	REGMAP_IRQ_REG_LINE(MT6360_DETACH_I, 8),
+	REGMAP_IRQ_REG_LINE(MT6360_QC30_STPDONE, 8),
+	REGMAP_IRQ_REG_LINE(MT6360_QC_VBUSDET_DONE, 8),
+	REGMAP_IRQ_REG_LINE(MT6360_HVDCP_DET, 8),
+	REGMAP_IRQ_REG_LINE(MT6360_CHGDETI, 8),
+	REGMAP_IRQ_REG_LINE(MT6360_DCDTI, 8),
+	REGMAP_IRQ_REG_LINE(MT6360_FOD_DONE_EVT, 8),
+	REGMAP_IRQ_REG_LINE(MT6360_FOD_OV_EVT, 8),
+	REGMAP_IRQ_REG_LINE(MT6360_CHRDET_UVP_EVT, 8),
+	REGMAP_IRQ_REG_LINE(MT6360_CHRDET_OVP_EVT, 8),
+	REGMAP_IRQ_REG_LINE(MT6360_CHRDET_EXT_EVT, 8),
+	REGMAP_IRQ_REG_LINE(MT6360_FOD_LR_EVT, 8),
+	REGMAP_IRQ_REG_LINE(MT6360_FOD_HR_EVT, 8),
+	REGMAP_IRQ_REG_LINE(MT6360_FOD_DISCHG_FAIL_EVT, 8),
+	REGMAP_IRQ_REG_LINE(MT6360_USBID_EVT, 8),
+	REGMAP_IRQ_REG_LINE(MT6360_APWDTRST_EVT, 8),
+	REGMAP_IRQ_REG_LINE(MT6360_EN_EVT, 8),
+	REGMAP_IRQ_REG_LINE(MT6360_QONB_RST_EVT, 8),
+	REGMAP_IRQ_REG_LINE(MT6360_MRSTB_EVT, 8),
+	REGMAP_IRQ_REG_LINE(MT6360_OTP_EVT, 8),
+	REGMAP_IRQ_REG_LINE(MT6360_VDDAOV_EVT, 8),
+	REGMAP_IRQ_REG_LINE(MT6360_SYSUV_EVT, 8),
+	REGMAP_IRQ_REG_LINE(MT6360_FLED_STRBPIN_EVT, 8),
+	REGMAP_IRQ_REG_LINE(MT6360_FLED_TORPIN_EVT, 8),
+	REGMAP_IRQ_REG_LINE(MT6360_FLED_TX_EVT, 8),
+	REGMAP_IRQ_REG_LINE(MT6360_FLED_LVF_EVT, 8),
+	REGMAP_IRQ_REG_LINE(MT6360_FLED2_SHORT_EVT, 8),
+	REGMAP_IRQ_REG_LINE(MT6360_FLED1_SHORT_EVT, 8),
+	REGMAP_IRQ_REG_LINE(MT6360_FLED2_STRB_EVT, 8),
+	REGMAP_IRQ_REG_LINE(MT6360_FLED1_STRB_EVT, 8),
+	REGMAP_IRQ_REG_LINE(MT6360_FLED2_STRB_TO_EVT, 8),
+	REGMAP_IRQ_REG_LINE(MT6360_FLED1_STRB_TO_EVT, 8),
+	REGMAP_IRQ_REG_LINE(MT6360_FLED2_TOR_EVT, 8),
+	REGMAP_IRQ_REG_LINE(MT6360_FLED1_TOR_EVT, 8),
+	REGMAP_IRQ_REG_LINE(MT6360_BUCK1_PGB_EVT, 8),
+	REGMAP_IRQ_REG_LINE(MT6360_BUCK1_OC_EVT, 8),
+	REGMAP_IRQ_REG_LINE(MT6360_BUCK1_OV_EVT, 8),
+	REGMAP_IRQ_REG_LINE(MT6360_BUCK1_UV_EVT, 8),
+	REGMAP_IRQ_REG_LINE(MT6360_BUCK2_PGB_EVT, 8),
+	REGMAP_IRQ_REG_LINE(MT6360_BUCK2_OC_EVT, 8),
+	REGMAP_IRQ_REG_LINE(MT6360_BUCK2_OV_EVT, 8),
+	REGMAP_IRQ_REG_LINE(MT6360_BUCK2_UV_EVT, 8),
+	REGMAP_IRQ_REG_LINE(MT6360_LDO1_OC_EVT, 8),
+	REGMAP_IRQ_REG_LINE(MT6360_LDO2_OC_EVT, 8),
+	REGMAP_IRQ_REG_LINE(MT6360_LDO3_OC_EVT, 8),
+	REGMAP_IRQ_REG_LINE(MT6360_LDO5_OC_EVT, 8),
+	REGMAP_IRQ_REG_LINE(MT6360_LDO6_OC_EVT, 8),
+	REGMAP_IRQ_REG_LINE(MT6360_LDO7_OC_EVT, 8),
+	REGMAP_IRQ_REG_LINE(MT6360_LDO1_PGB_EVT, 8),
+	REGMAP_IRQ_REG_LINE(MT6360_LDO2_PGB_EVT, 8),
+	REGMAP_IRQ_REG_LINE(MT6360_LDO3_PGB_EVT, 8),
+	REGMAP_IRQ_REG_LINE(MT6360_LDO5_PGB_EVT, 8),
+	REGMAP_IRQ_REG_LINE(MT6360_LDO6_PGB_EVT, 8),
+	REGMAP_IRQ_REG_LINE(MT6360_LDO7_PGB_EVT, 8),
+};
+
+static int mt6360_pmu_handle_post_irq(void *irq_drv_data)
+{
+	struct mt6360_pmu_data *mpd = irq_drv_data;
+
+	return regmap_update_bits(mpd->regmap,
+		MT6360_PMU_IRQ_SET, MT6360_IRQ_RETRIG, MT6360_IRQ_RETRIG);
+}
+
+static struct regmap_irq_chip mt6360_pmu_irq_chip = {
+	.irqs = mt6360_pmu_irqs,
+	.num_irqs = ARRAY_SIZE(mt6360_pmu_irqs),
+	.num_regs = MT6360_PMU_IRQ_REGNUM,
+	.mask_base = MT6360_PMU_CHG_MASK1,
+	.status_base = MT6360_PMU_CHG_IRQ1,
+	.ack_base = MT6360_PMU_CHG_IRQ1,
+	.init_ack_masked = true,
+	.use_ack = true,
+	.handle_post_irq = mt6360_pmu_handle_post_irq,
+};
+
+static const struct regmap_config mt6360_pmu_regmap_config = {
+	.reg_bits = 8,
+	.val_bits = 8,
+	.max_register = MT6360_PMU_MAXREG,
+};
+
+static const struct resource mt6360_adc_resources[] = {
+	DEFINE_RES_IRQ_NAMED(MT6360_ADC_DONEI, "adc_donei"),
+};
+
+static const struct resource mt6360_chg_resources[] = {
+	DEFINE_RES_IRQ_NAMED(MT6360_CHG_TREG_EVT, "chg_treg_evt"),
+	DEFINE_RES_IRQ_NAMED(MT6360_PWR_RDY_EVT, "pwr_rdy_evt"),
+	DEFINE_RES_IRQ_NAMED(MT6360_CHG_BATSYSUV_EVT, "chg_batsysuv_evt"),
+	DEFINE_RES_IRQ_NAMED(MT6360_CHG_VSYSUV_EVT, "chg_vsysuv_evt"),
+	DEFINE_RES_IRQ_NAMED(MT6360_CHG_VSYSOV_EVT, "chg_vsysov_evt"),
+	DEFINE_RES_IRQ_NAMED(MT6360_CHG_VBATOV_EVT, "chg_vbatov_evt"),
+	DEFINE_RES_IRQ_NAMED(MT6360_CHG_VBUSOV_EVT, "chg_vbusov_evt"),
+	DEFINE_RES_IRQ_NAMED(MT6360_CHG_AICCMEASL, "chg_aiccmeasl"),
+	DEFINE_RES_IRQ_NAMED(MT6360_WDTMRI, "wdtmri"),
+	DEFINE_RES_IRQ_NAMED(MT6360_CHG_RECHGI, "chg_rechgi"),
+	DEFINE_RES_IRQ_NAMED(MT6360_CHG_TERMI, "chg_termi"),
+	DEFINE_RES_IRQ_NAMED(MT6360_CHG_IEOCI, "chg_ieoci"),
+	DEFINE_RES_IRQ_NAMED(MT6360_PUMPX_DONEI, "pumpx_donei"),
+	DEFINE_RES_IRQ_NAMED(MT6360_ATTACH_I, "attach_i"),
+	DEFINE_RES_IRQ_NAMED(MT6360_CHRDET_EXT_EVT, "chrdet_ext_evt"),
+};
+
+static const struct resource mt6360_led_resources[] = {
+	DEFINE_RES_IRQ_NAMED(MT6360_FLED_CHG_VINOVP_EVT, "fled_chg_vinovp_evt"),
+	DEFINE_RES_IRQ_NAMED(MT6360_FLED_LVF_EVT, "fled_lvf_evt"),
+	DEFINE_RES_IRQ_NAMED(MT6360_FLED2_SHORT_EVT, "fled2_short_evt"),
+	DEFINE_RES_IRQ_NAMED(MT6360_FLED1_SHORT_EVT, "fled1_short_evt"),
+	DEFINE_RES_IRQ_NAMED(MT6360_FLED2_STRB_TO_EVT, "fled2_strb_to_evt"),
+	DEFINE_RES_IRQ_NAMED(MT6360_FLED1_STRB_TO_EVT, "fled1_strb_to_evt"),
+};
+
+static const struct resource mt6360_pmic_resources[] = {
+	DEFINE_RES_IRQ_NAMED(MT6360_BUCK1_PGB_EVT, "buck1_pgb_evt"),
+	DEFINE_RES_IRQ_NAMED(MT6360_BUCK1_OC_EVT, "buck1_oc_evt"),
+	DEFINE_RES_IRQ_NAMED(MT6360_BUCK1_OV_EVT, "buck1_ov_evt"),
+	DEFINE_RES_IRQ_NAMED(MT6360_BUCK1_UV_EVT, "buck1_uv_evt"),
+	DEFINE_RES_IRQ_NAMED(MT6360_BUCK2_PGB_EVT, "buck2_pgb_evt"),
+	DEFINE_RES_IRQ_NAMED(MT6360_BUCK2_OC_EVT, "buck2_oc_evt"),
+	DEFINE_RES_IRQ_NAMED(MT6360_BUCK2_OV_EVT, "buck2_ov_evt"),
+	DEFINE_RES_IRQ_NAMED(MT6360_BUCK2_UV_EVT, "buck2_uv_evt"),
+	DEFINE_RES_IRQ_NAMED(MT6360_LDO6_OC_EVT, "ldo6_oc_evt"),
+	DEFINE_RES_IRQ_NAMED(MT6360_LDO7_OC_EVT, "ldo7_oc_evt"),
+	DEFINE_RES_IRQ_NAMED(MT6360_LDO6_PGB_EVT, "ldo6_pgb_evt"),
+	DEFINE_RES_IRQ_NAMED(MT6360_LDO7_PGB_EVT, "ldo7_pgb_evt"),
+};
+
+static const struct resource mt6360_ldo_resources[] = {
+	DEFINE_RES_IRQ_NAMED(MT6360_LDO1_OC_EVT, "ldo1_oc_evt"),
+	DEFINE_RES_IRQ_NAMED(MT6360_LDO2_OC_EVT, "ldo2_oc_evt"),
+	DEFINE_RES_IRQ_NAMED(MT6360_LDO3_OC_EVT, "ldo3_oc_evt"),
+	DEFINE_RES_IRQ_NAMED(MT6360_LDO5_OC_EVT, "ldo5_oc_evt"),
+	DEFINE_RES_IRQ_NAMED(MT6360_LDO1_PGB_EVT, "ldo1_pgb_evt"),
+	DEFINE_RES_IRQ_NAMED(MT6360_LDO2_PGB_EVT, "ldo2_pgb_evt"),
+	DEFINE_RES_IRQ_NAMED(MT6360_LDO3_PGB_EVT, "ldo3_pgb_evt"),
+	DEFINE_RES_IRQ_NAMED(MT6360_LDO5_PGB_EVT, "ldo5_pgb_evt"),
+};
+
+static const struct mfd_cell mt6360_devs[] = {
+	OF_MFD_CELL("mt6360_adc", mt6360_adc_resources,
+		    NULL, 0, 0, "mediatek,mt6360_adc"),
+	OF_MFD_CELL("mt6360_chg", mt6360_chg_resources,
+		    NULL, 0, 0, "mediatek,mt6360_chg"),
+	OF_MFD_CELL("mt6360_led", mt6360_led_resources,
+		    NULL, 0, 0, "mediatek,mt6360_led"),
+	OF_MFD_CELL("mt6360_pmic", mt6360_pmic_resources,
+		    NULL, 0, 0, "mediatek,mt6360_pmic"),
+	OF_MFD_CELL("mt6360_ldo", mt6360_ldo_resources,
+		    NULL, 0, 0, "mediatek,mt6360_ldo"),
+	OF_MFD_CELL("mt6360_tcpc", NULL,
+		    NULL, 0, 0, "mediatek,mt6360_tcpc"),
+};
+
+static const unsigned short mt6360_slave_addr[MT6360_SLAVE_MAX] = {
+	MT6360_PMU_SLAVEID,
+	MT6360_PMIC_SLAVEID,
+	MT6360_LDO_SLAVEID,
+	MT6360_TCPC_SLAVEID,
+};
+
+static int mt6360_pmu_probe(struct i2c_client *client)
+{
+	struct mt6360_pmu_data *mpd;
+	unsigned int reg_data;
+	int i, ret;
+
+	mpd = devm_kzalloc(&client->dev, sizeof(*mpd), GFP_KERNEL);
+	if (!mpd)
+		return -ENOMEM;
+
+	mpd->dev = &client->dev;
+	i2c_set_clientdata(client, mpd);
+
+	mpd->regmap = devm_regmap_init_i2c(client, &mt6360_pmu_regmap_config);
+	if (IS_ERR(mpd->regmap)) {
+		dev_err(&client->dev, "Failed to register regmap\n");
+		return PTR_ERR(mpd->regmap);
+	}
+
+	ret = regmap_read(mpd->regmap, MT6360_PMU_DEV_INFO, &reg_data);
+	if (ret) {
+		dev_err(&client->dev, "Device not found\n");
+		return ret;
+	}
+
+	mpd->chip_rev = reg_data & CHIP_REV_MASK;
+	if (mpd->chip_rev != CHIP_VEN_MT6360) {
+		dev_err(&client->dev, "Device not supported\n");
+		return -ENODEV;
+	}
+
+	mt6360_pmu_irq_chip.irq_drv_data = mpd;
+	ret = devm_regmap_add_irq_chip(&client->dev, mpd->regmap, client->irq,
+				       IRQF_TRIGGER_FALLING, 0,
+				       &mt6360_pmu_irq_chip, &mpd->irq_data);
+	if (ret) {
+		dev_err(&client->dev, "Failed to add Regmap IRQ Chip\n");
+		return ret;
+	}
+
+	mpd->i2c[0] = client;
+	for (i = 1; i < MT6360_SLAVE_MAX; i++) {
+		mpd->i2c[i] = devm_i2c_new_dummy_device(&client->dev,
+							client->adapter,
+							mt6360_slave_addr[i]);
+		if (IS_ERR(mpd->i2c[i])) {
+			dev_err(&client->dev,
+				"Failed to get new dummy I2C device for address 0x%x",
+				mt6360_slave_addr[i]);
+			return PTR_ERR(mpd->i2c[i]);
+		}
+		i2c_set_clientdata(mpd->i2c[i], mpd);
+	}
+
+	ret = devm_mfd_add_devices(&client->dev, PLATFORM_DEVID_AUTO,
+				   mt6360_devs, ARRAY_SIZE(mt6360_devs), NULL,
+				   0, regmap_irq_get_domain(mpd->irq_data));
+	if (ret) {
+		dev_err(&client->dev,
+			"Failed to register subordinate devices\n");
+		return ret;
+	}
+
+	return 0;
+}
+
+static int __maybe_unused mt6360_pmu_suspend(struct device *dev)
+{
+	struct i2c_client *i2c = to_i2c_client(dev);
+
+	if (device_may_wakeup(dev))
+		enable_irq_wake(i2c->irq);
+
+	return 0;
+}
+
+static int __maybe_unused mt6360_pmu_resume(struct device *dev)
+{
+
+	struct i2c_client *i2c = to_i2c_client(dev);
+
+	if (device_may_wakeup(dev))
+		disable_irq_wake(i2c->irq);
+
+	return 0;
+}
+
+static SIMPLE_DEV_PM_OPS(mt6360_pmu_pm_ops,
+			 mt6360_pmu_suspend, mt6360_pmu_resume);
+
+static const struct of_device_id __maybe_unused mt6360_pmu_of_id[] = {
+	{ .compatible = "mediatek,mt6360_pmu", },
+	{},
+};
+MODULE_DEVICE_TABLE(of, mt6360_pmu_of_id);
+
+static struct i2c_driver mt6360_pmu_driver = {
+	.driver = {
+		.pm = &mt6360_pmu_pm_ops,
+		.of_match_table = of_match_ptr(mt6360_pmu_of_id),
+	},
+	.probe_new = mt6360_pmu_probe,
+};
+module_i2c_driver(mt6360_pmu_driver);
+
+MODULE_AUTHOR("Gene Chen <gene_chen@richtek.com>");
+MODULE_DESCRIPTION("MT6360 PMU I2C Driver");
+MODULE_LICENSE("GPL v2");
diff --git a/include/linux/mfd/mt6360.h b/include/linux/mfd/mt6360.h
new file mode 100644
index 0000000..c03e6d1
--- /dev/null
+++ b/include/linux/mfd/mt6360.h
@@ -0,0 +1,240 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (c) 2019 MediaTek Inc.
+ */
+
+#ifndef __MT6360_H__
+#define __MT6360_H__
+
+#include <linux/regmap.h>
+
+enum {
+	MT6360_SLAVE_PMU = 0,
+	MT6360_SLAVE_PMIC,
+	MT6360_SLAVE_LDO,
+	MT6360_SLAVE_TCPC,
+	MT6360_SLAVE_MAX,
+};
+
+#define MT6360_PMU_SLAVEID	(0x34)
+#define MT6360_PMIC_SLAVEID	(0x1A)
+#define MT6360_LDO_SLAVEID	(0x64)
+#define MT6360_TCPC_SLAVEID	(0x4E)
+
+struct mt6360_pmu_data {
+	struct i2c_client *i2c[MT6360_SLAVE_MAX];
+	struct device *dev;
+	struct regmap *regmap;
+	struct regmap_irq_chip_data *irq_data;
+	unsigned int chip_rev;
+};
+
+/* PMU register defininition */
+#define MT6360_PMU_DEV_INFO			(0x00)
+#define MT6360_PMU_CORE_CTRL1			(0x01)
+#define MT6360_PMU_RST1				(0x02)
+#define MT6360_PMU_CRCEN			(0x03)
+#define MT6360_PMU_RST_PAS_CODE1		(0x04)
+#define MT6360_PMU_RST_PAS_CODE2		(0x05)
+#define MT6360_PMU_CORE_CTRL2			(0x06)
+#define MT6360_PMU_TM_PAS_CODE1			(0x07)
+#define MT6360_PMU_TM_PAS_CODE2			(0x08)
+#define MT6360_PMU_TM_PAS_CODE3			(0x09)
+#define MT6360_PMU_TM_PAS_CODE4			(0x0A)
+#define MT6360_PMU_IRQ_IND			(0x0B)
+#define MT6360_PMU_IRQ_MASK			(0x0C)
+#define MT6360_PMU_IRQ_SET			(0x0D)
+#define MT6360_PMU_SHDN_CTRL			(0x0E)
+#define MT6360_PMU_TM_INF			(0x0F)
+#define MT6360_PMU_I2C_CTRL			(0x10)
+#define MT6360_PMU_CHG_CTRL1			(0x11)
+#define MT6360_PMU_CHG_CTRL2			(0x12)
+#define MT6360_PMU_CHG_CTRL3			(0x13)
+#define MT6360_PMU_CHG_CTRL4			(0x14)
+#define MT6360_PMU_CHG_CTRL5			(0x15)
+#define MT6360_PMU_CHG_CTRL6			(0x16)
+#define MT6360_PMU_CHG_CTRL7			(0x17)
+#define MT6360_PMU_CHG_CTRL8			(0x18)
+#define MT6360_PMU_CHG_CTRL9			(0x19)
+#define MT6360_PMU_CHG_CTRL10			(0x1A)
+#define MT6360_PMU_CHG_CTRL11			(0x1B)
+#define MT6360_PMU_CHG_CTRL12			(0x1C)
+#define MT6360_PMU_CHG_CTRL13			(0x1D)
+#define MT6360_PMU_CHG_CTRL14			(0x1E)
+#define MT6360_PMU_CHG_CTRL15			(0x1F)
+#define MT6360_PMU_CHG_CTRL16			(0x20)
+#define MT6360_PMU_CHG_AICC_RESULT		(0x21)
+#define MT6360_PMU_DEVICE_TYPE			(0x22)
+#define MT6360_PMU_QC_CONTROL1			(0x23)
+#define MT6360_PMU_QC_CONTROL2			(0x24)
+#define MT6360_PMU_QC30_CONTROL1		(0x25)
+#define MT6360_PMU_QC30_CONTROL2		(0x26)
+#define MT6360_PMU_USB_STATUS1			(0x27)
+#define MT6360_PMU_QC_STATUS1			(0x28)
+#define MT6360_PMU_QC_STATUS2			(0x29)
+#define MT6360_PMU_CHG_PUMP			(0x2A)
+#define MT6360_PMU_CHG_CTRL17			(0x2B)
+#define MT6360_PMU_CHG_CTRL18			(0x2C)
+#define MT6360_PMU_CHRDET_CTRL1			(0x2D)
+#define MT6360_PMU_CHRDET_CTRL2			(0x2E)
+#define MT6360_PMU_DPDN_CTRL			(0x2F)
+#define MT6360_PMU_CHG_HIDDEN_CTRL1		(0x30)
+#define MT6360_PMU_CHG_HIDDEN_CTRL2		(0x31)
+#define MT6360_PMU_CHG_HIDDEN_CTRL3		(0x32)
+#define MT6360_PMU_CHG_HIDDEN_CTRL4		(0x33)
+#define MT6360_PMU_CHG_HIDDEN_CTRL5		(0x34)
+#define MT6360_PMU_CHG_HIDDEN_CTRL6		(0x35)
+#define MT6360_PMU_CHG_HIDDEN_CTRL7		(0x36)
+#define MT6360_PMU_CHG_HIDDEN_CTRL8		(0x37)
+#define MT6360_PMU_CHG_HIDDEN_CTRL9		(0x38)
+#define MT6360_PMU_CHG_HIDDEN_CTRL10		(0x39)
+#define MT6360_PMU_CHG_HIDDEN_CTRL11		(0x3A)
+#define MT6360_PMU_CHG_HIDDEN_CTRL12		(0x3B)
+#define MT6360_PMU_CHG_HIDDEN_CTRL13		(0x3C)
+#define MT6360_PMU_CHG_HIDDEN_CTRL14		(0x3D)
+#define MT6360_PMU_CHG_HIDDEN_CTRL15		(0x3E)
+#define MT6360_PMU_CHG_HIDDEN_CTRL16		(0x3F)
+#define MT6360_PMU_CHG_HIDDEN_CTRL17		(0x40)
+#define MT6360_PMU_CHG_HIDDEN_CTRL18		(0x41)
+#define MT6360_PMU_CHG_HIDDEN_CTRL19		(0x42)
+#define MT6360_PMU_CHG_HIDDEN_CTRL20		(0x43)
+#define MT6360_PMU_CHG_HIDDEN_CTRL21		(0x44)
+#define MT6360_PMU_CHG_HIDDEN_CTRL22		(0x45)
+#define MT6360_PMU_CHG_HIDDEN_CTRL23		(0x46)
+#define MT6360_PMU_CHG_HIDDEN_CTRL24		(0x47)
+#define MT6360_PMU_CHG_HIDDEN_CTRL25		(0x48)
+#define MT6360_PMU_BC12_CTRL			(0x49)
+#define MT6360_PMU_CHG_STAT			(0x4A)
+#define MT6360_PMU_RESV1			(0x4B)
+#define MT6360_PMU_TYPEC_OTP_TH_SEL_CODEH	(0x4E)
+#define MT6360_PMU_TYPEC_OTP_TH_SEL_CODEL	(0x4F)
+#define MT6360_PMU_TYPEC_OTP_HYST_TH		(0x50)
+#define MT6360_PMU_TYPEC_OTP_CTRL		(0x51)
+#define MT6360_PMU_ADC_BAT_DATA_H		(0x52)
+#define MT6360_PMU_ADC_BAT_DATA_L		(0x53)
+#define MT6360_PMU_IMID_BACKBST_ON		(0x54)
+#define MT6360_PMU_IMID_BACKBST_OFF		(0x55)
+#define MT6360_PMU_ADC_CONFIG			(0x56)
+#define MT6360_PMU_ADC_EN2			(0x57)
+#define MT6360_PMU_ADC_IDLE_T			(0x58)
+#define MT6360_PMU_ADC_RPT_1			(0x5A)
+#define MT6360_PMU_ADC_RPT_2			(0x5B)
+#define MT6360_PMU_ADC_RPT_3			(0x5C)
+#define MT6360_PMU_ADC_RPT_ORG1			(0x5D)
+#define MT6360_PMU_ADC_RPT_ORG2			(0x5E)
+#define MT6360_PMU_BAT_OVP_TH_SEL_CODEH		(0x5F)
+#define MT6360_PMU_BAT_OVP_TH_SEL_CODEL		(0x60)
+#define MT6360_PMU_CHG_CTRL19			(0x61)
+#define MT6360_PMU_VDDASUPPLY			(0x62)
+#define MT6360_PMU_BC12_MANUAL			(0x63)
+#define MT6360_PMU_CHGDET_FUNC			(0x64)
+#define MT6360_PMU_FOD_CTRL			(0x65)
+#define MT6360_PMU_CHG_CTRL20			(0x66)
+#define MT6360_PMU_CHG_HIDDEN_CTRL26		(0x67)
+#define MT6360_PMU_CHG_HIDDEN_CTRL27		(0x68)
+#define MT6360_PMU_RESV2			(0x69)
+#define MT6360_PMU_USBID_CTRL1			(0x6D)
+#define MT6360_PMU_USBID_CTRL2			(0x6E)
+#define MT6360_PMU_USBID_CTRL3			(0x6F)
+#define MT6360_PMU_FLED_CFG			(0x70)
+#define MT6360_PMU_RESV3			(0x71)
+#define MT6360_PMU_FLED1_CTRL			(0x72)
+#define MT6360_PMU_FLED_STRB_CTRL		(0x73)
+#define MT6360_PMU_FLED1_STRB_CTRL2		(0x74)
+#define MT6360_PMU_FLED1_TOR_CTRL		(0x75)
+#define MT6360_PMU_FLED2_CTRL			(0x76)
+#define MT6360_PMU_RESV4			(0x77)
+#define MT6360_PMU_FLED2_STRB_CTRL2		(0x78)
+#define MT6360_PMU_FLED2_TOR_CTRL		(0x79)
+#define MT6360_PMU_FLED_VMIDTRK_CTRL1		(0x7A)
+#define MT6360_PMU_FLED_VMID_RTM		(0x7B)
+#define MT6360_PMU_FLED_VMIDTRK_CTRL2		(0x7C)
+#define MT6360_PMU_FLED_PWSEL			(0x7D)
+#define MT6360_PMU_FLED_EN			(0x7E)
+#define MT6360_PMU_FLED_Hidden1			(0x7F)
+#define MT6360_PMU_RGB_EN			(0x80)
+#define MT6360_PMU_RGB1_ISNK			(0x81)
+#define MT6360_PMU_RGB2_ISNK			(0x82)
+#define MT6360_PMU_RGB3_ISNK			(0x83)
+#define MT6360_PMU_RGB_ML_ISNK			(0x84)
+#define MT6360_PMU_RGB1_DIM			(0x85)
+#define MT6360_PMU_RGB2_DIM			(0x86)
+#define MT6360_PMU_RGB3_DIM			(0x87)
+#define MT6360_PMU_RESV5			(0x88)
+#define MT6360_PMU_RGB12_Freq			(0x89)
+#define MT6360_PMU_RGB34_Freq			(0x8A)
+#define MT6360_PMU_RGB1_Tr			(0x8B)
+#define MT6360_PMU_RGB1_Tf			(0x8C)
+#define MT6360_PMU_RGB1_TON_TOFF		(0x8D)
+#define MT6360_PMU_RGB2_Tr			(0x8E)
+#define MT6360_PMU_RGB2_Tf			(0x8F)
+#define MT6360_PMU_RGB2_TON_TOFF		(0x90)
+#define MT6360_PMU_RGB3_Tr			(0x91)
+#define MT6360_PMU_RGB3_Tf			(0x92)
+#define MT6360_PMU_RGB3_TON_TOFF		(0x93)
+#define MT6360_PMU_RGB_Hidden_CTRL1		(0x94)
+#define MT6360_PMU_RGB_Hidden_CTRL2		(0x95)
+#define MT6360_PMU_RESV6			(0x97)
+#define MT6360_PMU_SPARE1			(0x9A)
+#define MT6360_PMU_SPARE2			(0xA0)
+#define MT6360_PMU_SPARE3			(0xB0)
+#define MT6360_PMU_SPARE4			(0xC0)
+#define MT6360_PMU_CHG_IRQ1			(0xD0)
+#define MT6360_PMU_CHG_IRQ2			(0xD1)
+#define MT6360_PMU_CHG_IRQ3			(0xD2)
+#define MT6360_PMU_CHG_IRQ4			(0xD3)
+#define MT6360_PMU_CHG_IRQ5			(0xD4)
+#define MT6360_PMU_CHG_IRQ6			(0xD5)
+#define MT6360_PMU_QC_IRQ			(0xD6)
+#define MT6360_PMU_FOD_IRQ			(0xD7)
+#define MT6360_PMU_BASE_IRQ			(0xD8)
+#define MT6360_PMU_FLED_IRQ1			(0xD9)
+#define MT6360_PMU_FLED_IRQ2			(0xDA)
+#define MT6360_PMU_RGB_IRQ			(0xDB)
+#define MT6360_PMU_BUCK1_IRQ			(0xDC)
+#define MT6360_PMU_BUCK2_IRQ			(0xDD)
+#define MT6360_PMU_LDO_IRQ1			(0xDE)
+#define MT6360_PMU_LDO_IRQ2			(0xDF)
+#define MT6360_PMU_CHG_STAT1			(0xE0)
+#define MT6360_PMU_CHG_STAT2			(0xE1)
+#define MT6360_PMU_CHG_STAT3			(0xE2)
+#define MT6360_PMU_CHG_STAT4			(0xE3)
+#define MT6360_PMU_CHG_STAT5			(0xE4)
+#define MT6360_PMU_CHG_STAT6			(0xE5)
+#define MT6360_PMU_QC_STAT			(0xE6)
+#define MT6360_PMU_FOD_STAT			(0xE7)
+#define MT6360_PMU_BASE_STAT			(0xE8)
+#define MT6360_PMU_FLED_STAT1			(0xE9)
+#define MT6360_PMU_FLED_STAT2			(0xEA)
+#define MT6360_PMU_RGB_STAT			(0xEB)
+#define MT6360_PMU_BUCK1_STAT			(0xEC)
+#define MT6360_PMU_BUCK2_STAT			(0xED)
+#define MT6360_PMU_LDO_STAT1			(0xEE)
+#define MT6360_PMU_LDO_STAT2			(0xEF)
+#define MT6360_PMU_CHG_MASK1			(0xF0)
+#define MT6360_PMU_CHG_MASK2			(0xF1)
+#define MT6360_PMU_CHG_MASK3			(0xF2)
+#define MT6360_PMU_CHG_MASK4			(0xF3)
+#define MT6360_PMU_CHG_MASK5			(0xF4)
+#define MT6360_PMU_CHG_MASK6			(0xF5)
+#define MT6360_PMU_QC_MASK			(0xF6)
+#define MT6360_PMU_FOD_MASK			(0xF7)
+#define MT6360_PMU_BASE_MASK			(0xF8)
+#define MT6360_PMU_FLED_MASK1			(0xF9)
+#define MT6360_PMU_FLED_MASK2			(0xFA)
+#define MT6360_PMU_FAULTB_MASK			(0xFB)
+#define MT6360_PMU_BUCK1_MASK			(0xFC)
+#define MT6360_PMU_BUCK2_MASK			(0xFD)
+#define MT6360_PMU_LDO_MASK1			(0xFE)
+#define MT6360_PMU_LDO_MASK2			(0xFF)
+#define MT6360_PMU_MAXREG			(MT6360_PMU_LDO_MASK2)
+
+/* MT6360_PMU_IRQ_SET */
+#define MT6360_PMU_IRQ_REGNUM	(MT6360_PMU_LDO_IRQ2 - MT6360_PMU_CHG_IRQ1 + 1)
+#define MT6360_IRQ_RETRIG	BIT(2)
+
+#define CHIP_VEN_MASK				(0xF0)
+#define CHIP_VEN_MT6360				(0x50)
+#define CHIP_REV_MASK				(0x0F)
+
+#endif /* __MT6360_H__ */
-- 
2.7.4


^ permalink raw reply related	[flat|nested] 414+ messages in thread
* (no subject)
@ 2020-02-11 22:34 Rajat Jain
  2020-02-12  9:30 ` Jarkko Nikula
  0 siblings, 1 reply; 414+ messages in thread
From: Rajat Jain @ 2020-02-11 22:34 UTC (permalink / raw)
  To: Daniel Mack, Haojian Zhuang, Robert Jarzmik, Mark Brown,
	linux-arm-kernel, linux-spi, linux-kernel
  Cc: Evan Green, rajatja, rajatxjain, evgreen, shobhit.srivastava,
	porselvan.muthukrishnan

From: Evan Green <evgreen@chromium.org>

Date: Wed, 29 Jan 2020 13:54:16 -0800
Subject: [PATCH] spi: pxa2xx: Add CS control clock quirk

In some circumstances on Intel LPSS controllers, toggling the LPSS
CS control register doesn't actually cause the CS line to toggle.
This seems to be failure of dynamic clock gating that occurs after
going through a suspend/resume transition, where the controller
is sent through a reset transition. This ruins SPI transactions
that either rely on delay_usecs, or toggle the CS line without
sending data.

Whenever CS is toggled, momentarily set the clock gating register
to "Force On" to poke the controller into acting on CS.

Signed-off-by: Evan Green <evgreen@chromium.org>
Signed-off-by: Rajat Jain <rajatja@google.com>
---
 drivers/spi/spi-pxa2xx.c | 23 +++++++++++++++++++++++
 1 file changed, 23 insertions(+)

diff --git a/drivers/spi/spi-pxa2xx.c b/drivers/spi/spi-pxa2xx.c
index 4c7a71f0fb3e..2e318158fca9 100644
--- a/drivers/spi/spi-pxa2xx.c
+++ b/drivers/spi/spi-pxa2xx.c
@@ -70,6 +70,10 @@ MODULE_ALIAS("platform:pxa2xx-spi");
 #define LPSS_CAPS_CS_EN_SHIFT			9
 #define LPSS_CAPS_CS_EN_MASK			(0xf << LPSS_CAPS_CS_EN_SHIFT)
 
+#define LPSS_PRIV_CLOCK_GATE 0x38
+#define LPSS_PRIV_CLOCK_GATE_CLK_CTL_MASK 0x3
+#define LPSS_PRIV_CLOCK_GATE_CLK_CTL_FORCE_ON 0x3
+
 struct lpss_config {
 	/* LPSS offset from drv_data->ioaddr */
 	unsigned offset;
@@ -86,6 +90,8 @@ struct lpss_config {
 	unsigned cs_sel_shift;
 	unsigned cs_sel_mask;
 	unsigned cs_num;
+	/* Quirks */
+	unsigned cs_clk_stays_gated : 1;
 };
 
 /* Keep these sorted with enum pxa_ssp_type */
@@ -156,6 +162,7 @@ static const struct lpss_config lpss_platforms[] = {
 		.tx_threshold_hi = 56,
 		.cs_sel_shift = 8,
 		.cs_sel_mask = 3 << 8,
+		.cs_clk_stays_gated = true,
 	},
 };
 
@@ -383,6 +390,22 @@ static void lpss_ssp_cs_control(struct spi_device *spi, bool enable)
 	else
 		value |= LPSS_CS_CONTROL_CS_HIGH;
 	__lpss_ssp_write_priv(drv_data, config->reg_cs_ctrl, value);
+	if (config->cs_clk_stays_gated) {
+		u32 clkgate;
+
+		/*
+		 * Changing CS alone when dynamic clock gating is on won't
+		 * actually flip CS at that time. This ruins SPI transfers
+		 * that specify delays, or have no data. Toggle the clock mode
+		 * to force on briefly to poke the CS pin to move.
+		 */
+		clkgate = __lpss_ssp_read_priv(drv_data, LPSS_PRIV_CLOCK_GATE);
+		value = (clkgate & ~LPSS_PRIV_CLOCK_GATE_CLK_CTL_MASK) |
+			LPSS_PRIV_CLOCK_GATE_CLK_CTL_FORCE_ON;
+
+		__lpss_ssp_write_priv(drv_data, LPSS_PRIV_CLOCK_GATE, value);
+		__lpss_ssp_write_priv(drv_data, LPSS_PRIV_CLOCK_GATE, clkgate);
+	}
 }
 
 static void cs_assert(struct spi_device *spi)
-- 
2.25.0.225.g125e21ebc7-goog


^ permalink raw reply related	[flat|nested] 414+ messages in thread
[parent not found: <f618ed4d-05ce-75cd-8cd9-24d8fe5a2551@samsung.com>]
* Re:
@ 2019-10-27 21:36 Margaret Kwan Wing Han
  0 siblings, 0 replies; 414+ messages in thread
From: Margaret Kwan Wing Han @ 2019-10-27 21:36 UTC (permalink / raw)
  To: linux-kernel


I need a partner for a legal deal worth $30,500,000 if interested reply me for
more details.

Regards,
Margaret Kwan Wing

^ permalink raw reply	[flat|nested] 414+ messages in thread
* RE:
@ 2019-09-24 19:49 Venkat Subbiah
  0 siblings, 0 replies; 414+ messages in thread
From: Venkat Subbiah @ 2019-09-24 19:49 UTC (permalink / raw)
  To: Lakshman, lauren, laurenb, Lavanya, Quang, Ida Maupin, Morgan,
	linux kernel

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=us-ascii, Size: 962 bytes --]

Hello 


http://omniummjc.com/freeze.php?dpeh=knot10401
Venkat

























alpajqmka wmsyduztf Update: Back in stock. This won’t last long! qgaegip fuwzmnt isqhzstcc wqkejlrnt So the waters were healed unto this day, according to the saying of Elisha which he spake. hypyvykicy rthie oaqwwrrc mduzva wlsfg




























hvpaxzcxyb itkzynwabe ktekwxu xhxgvai eaumbu ofnltk chdfggsb ufpefiuq





























qzlfa swozrpya dasogbkjo srgeqy icdmg Then wrote Rehum the chancellor, and Shimshai the scribe, and the rest of their companions; the Dinaites, the Apharsathchites, the Tarpelites, the Apharsites, the Archevites, the Babylonians, the Susanchites, the Dehavites, and the Elamites, njhthme pbiyywck qbnonwfsv tefdeug shqdn
























zenjr These deals are only for our readers, but we aren’t sure how long they’ll be available, so go ahead and sign up while you can. ofizsykm lpjnznu zffglnqq hmtrq

^ permalink raw reply	[flat|nested] 414+ messages in thread
[parent not found: <CAK8P3a16=ktJm5B3c5-XS7SqVuHBY5+E2FwVUqbdOdWK-AUgSA@mail.gmail.com>]
[parent not found: <E1hUrZM-0007qA-Q8@sslproxy01.your-server.de>]
* [PATCH v6 0/3] add new ima hook ima_kexec_cmdline to measure kexec boot cmdline args
@ 2019-05-21  0:06 Prakhar Srivastava
  2019-05-21  0:06 ` [PATCH v6 2/3] add a new ima template field buf Prakhar Srivastava
  0 siblings, 1 reply; 414+ messages in thread
From: Prakhar Srivastava @ 2019-05-21  0:06 UTC (permalink / raw)
  To: linux-integrity, linux-security-module, linux-kernel
  Cc: mjg59, zohar, roberto.sassu, vgoyal, Prakhar Srivastava

The motive behind the patch series is to measure the boot cmdline args
used for soft reboot/kexec case.

For secure boot attestation, it is necessary to measure the kernel
command line and the kernel version. For cold boot, the boot loader
can be enhanced to measure these parameters.
(https://mjg59.dreamwidth.org/48897.html)
However, for attestation across soft reboot boundary, these values 
also need to be measured during kexec_file_load.

Currently for Kexec(kexec_file_load)/soft reboot scenario the boot cmdline
args for the next kernel are not measured. For 
normal case of boot/hardreboot the cmdline args are measured into the TPM.

The hash of boot command line is calculated and added to the current 
running kernel's measurement list.  On a soft reboot like kexec, the PCRs
are not reset to zero.  Refer to commit 94c3aac567a9 ("ima: on soft 
reboot, restore the measurement list") patch description.

To achive the above the patch series does the following
  -adds a new ima hook: ima_kexec_cmdline which measures the cmdline args
   into the ima log, behind a new ima policy entry KEXEC_CMDLINE.
  -since the cmldine args cannot be appraised, a new template field(buf) is
   added. The template field contains the buffer passed(cmldine args), which
   can be used to appraise/attest at a later stage.
  -call the ima_kexec_cmdline(...) hook from kexec_file_load call.

The ima logs need to carried over to the next kernel, which will be followed
up by other patchsets for x86_64 and arm64.

Changelog:
V6:
  -add a new ima hook and policy to measure the cmdline
    args(ima_kexec_cmdline)
  -add a new template field buf to contain the buffer measured.
  [suggested by Mimi Zohar]
   add new fields to ima_event_data to store/read buffer data.
  [suggested by Roberto]
  -call ima_kexec_cmdline from kexec_file_load path

v5:
  -add a new ima hook and policy to measure the cmdline
    args(ima_kexec_cmdline)
  -add a new template field buf to contain the buffer measured.
    [suggested by Mimi Zohar]
  -call ima_kexec_cmdline from kexec_file_load path

v4:
  - per feedback from LSM community, removed the LSM hook and renamed the
    IMA policy to KEXEC_CMDLINE

v3: (rebase changes to next-general)
  - Add policy checks for buffer[suggested by Mimi Zohar]
  - use the IMA_XATTR to add buffer
  - Add kexec_cmdline used for kexec file load
  - Add an LSM hook to allow usage by other LSM.[suggestd by Mimi Zohar]

v2:
  - Add policy checks for buffer[suggested by Mimi Zohar]
  - Add an LSM hook to allow usage by other LSM.[suggestd by Mimi Zohar]
  - use the IMA_XATTR to add buffer instead of sig template

v1:
  -Add kconfigs to control the ima_buffer_check
  -measure the cmdline args suffixed with the kernel file name
  -add the buffer to the template sig field.

Prakhar Srivastava (3):
  Add a new ima hook ima_kexec_cmdline to measure cmdline args
  add a new ima template field buf
  call ima_kexec_cmdline to measure the cmdline args

 Documentation/ABI/testing/ima_policy      |  1 +
 Documentation/security/IMA-templates.rst  |  2 +-
 include/linux/ima.h                       |  2 +
 kernel/kexec_file.c                       |  8 ++-
 security/integrity/ima/ima.h              |  3 +
 security/integrity/ima/ima_api.c          |  5 +-
 security/integrity/ima/ima_init.c         |  2 +-
 security/integrity/ima/ima_main.c         | 80 +++++++++++++++++++++++
 security/integrity/ima/ima_policy.c       |  9 +++
 security/integrity/ima/ima_template.c     |  2 +
 security/integrity/ima/ima_template_lib.c | 20 ++++++
 security/integrity/ima/ima_template_lib.h |  4 ++
 12 files changed, 131 insertions(+), 7 deletions(-)

-- 
2.17.1


^ permalink raw reply	[flat|nested] 414+ messages in thread
* RE,
@ 2019-04-12 23:06 Sharifah Ahmad Mustahfa
  0 siblings, 0 replies; 414+ messages in thread
From: Sharifah Ahmad Mustahfa @ 2019-04-12 23:06 UTC (permalink / raw)
  To: linux-kernel

As-Salamu Alaykum, I need your help to transfer out the some amount of money, accumulated as undeclared excess profit made by me from the INVESTMENTS CAPITAL under my management in my bank. You will get 40% of the funds for your participation. Reply for more details thanks

^ permalink raw reply	[flat|nested] 414+ messages in thread
[parent not found: <20190319144116.400-1-mlevitsk@redhat.com>]
* RE,
@ 2019-03-13 23:49 LUIS EDUARDO CEPEDA CABRERA
  0 siblings, 0 replies; 414+ messages in thread
From: LUIS EDUARDO CEPEDA CABRERA @ 2019-03-13 23:49 UTC (permalink / raw)
  To: linux-kernel

Hello,

 i have a deal for you, can we work together ?

^ permalink raw reply	[flat|nested] 414+ messages in thread
* [PATCH] arch/arm/mm: Remove duplicate header
@ 2019-01-07 17:28 Souptick Joarder
  2019-01-17 11:23 ` Souptick Joarder
  0 siblings, 1 reply; 414+ messages in thread
From: Souptick Joarder @ 2019-01-07 17:28 UTC (permalink / raw)
  To: linux, mhocko, rppt, akpm
  Cc: linux-arm-kernel, linux-kernel, brajeswar.linux, sabyasachi.linux

Remove duplicate headers which are included twice.

Signed-off-by: Souptick Joarder <jrdr.linux@gmail.com>
---
 arch/arm/mm/mmu.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
index f5cc1cc..dde3032 100644
--- a/arch/arm/mm/mmu.c
+++ b/arch/arm/mm/mmu.c
@@ -23,7 +23,6 @@
 #include <asm/sections.h>
 #include <asm/cachetype.h>
 #include <asm/fixmap.h>
-#include <asm/sections.h>
 #include <asm/setup.h>
 #include <asm/smp_plat.h>
 #include <asm/tlb.h>
@@ -36,7 +35,6 @@
 #include <asm/mach/arch.h>
 #include <asm/mach/map.h>
 #include <asm/mach/pci.h>
-#include <asm/fixmap.h>
 
 #include "fault.h"
 #include "mm.h"
-- 
1.9.1


^ permalink raw reply related	[flat|nested] 414+ messages in thread
[parent not found: <CAMkWEXP4Mm5x9rdrKn9xRNVm7vxqoL62ftxb+UcJFAiJ+U9X3A@mail.gmail.com>]
[parent not found: <1530911788-7033-1-git-send-email-santosh.shilimkar@oracle.com>]
* (no subject)
@ 2018-01-11 17:16 Fabian Huegel
  2018-01-11 17:25 ` Ben Evans
  0 siblings, 1 reply; 414+ messages in thread
From: Fabian Huegel @ 2018-01-11 17:16 UTC (permalink / raw)
  To: Oleg Drokin, Andreas Dilger, James Simmons, Lai Siyao,
	John L . Hammond, Greg Kroah-Hartman, devel, Ben Evans,
	NeilBrown
  Cc: lustre-devel, linux-kernel, linux-kernel

We cleaned up a lot of checkpatch errors and warnings in obd_class.h,
but there are still some CHECKs and two warnings about flow control
inside macros left.

Changing those macros to inline functions would probably
be a good idea, unfortunatly it's not straightforward since they use
'#op' to print the name of the operation.

We also did some aligning to make the code more readable and removed
an unnecessary macro.

We only tested, that the kernel still compiles and the lustre kernel
module loads successfully, but given the harmless nature of these
changes we don't expect any problems.

The patches are based on the staging-testing branch of the staging tree.

^ permalink raw reply	[flat|nested] 414+ messages in thread
* Re:
@ 2017-11-13 14:55 Amos Kalonzo
  0 siblings, 0 replies; 414+ messages in thread
From: Amos Kalonzo @ 2017-11-13 14:55 UTC (permalink / raw)


Attn:

I am wondering why You haven't respond to my email for some days now.
reference to my client's contract balance payment of (11.7M,USD)
Kindly get back to me for more details.

Best Regards

Amos Kalonzo

^ permalink raw reply	[flat|nested] 414+ messages in thread
* Re:
@ 2017-09-07  8:50 Quick Loan
  0 siblings, 0 replies; 414+ messages in thread
From: Quick Loan @ 2017-09-07  8:50 UTC (permalink / raw)


Hello dear I am an International loan lender, I give out loans at 1% interest
rate, email me at:(rich_ken2016@usa.com)

^ permalink raw reply	[flat|nested] 414+ messages in thread
* Re:
@ 2017-08-18 19:47 Jessy
  0 siblings, 0 replies; 414+ messages in thread
From: Jessy @ 2017-08-18 19:47 UTC (permalink / raw)
  To: Recipients

Hello,


I wish to seek for your assistance in a deal that will be of mutual benefit for the both of us from Camp Stanley in Uijeongbu. Please contact me for details, God bless you.

^ permalink raw reply	[flat|nested] 414+ messages in thread
* Re:
@ 2017-07-15  3:29 Saif Al-Islam
  0 siblings, 0 replies; 414+ messages in thread
From: Saif Al-Islam @ 2017-07-15  3:29 UTC (permalink / raw)


I need your assistance in a transaction that will benefit you details
will be disclosed to you once i receive your reply.

Regards,
Saif.

^ permalink raw reply	[flat|nested] 414+ messages in thread
* RE:
@ 2017-07-07 17:04 Mrs Alice Walton
  0 siblings, 0 replies; 414+ messages in thread
From: Mrs Alice Walton @ 2017-07-07 17:04 UTC (permalink / raw)


-- 
my name is Mrs. Alice Walton, a business woman an America Citizen and  
the heiress to the fortune of Walmart stores, born October 7, 1949. I  
have a mission for you worth $100,000,000.00(Hundred Million United  
State Dollars) which I intend using for CHARITY PROJECT to help the  
less privilege and orphanage

^ permalink raw reply	[flat|nested] 414+ messages in thread
* RE:
@ 2017-05-28 13:39 Lasek László
  0 siblings, 0 replies; 414+ messages in thread
From: Lasek László @ 2017-05-28 13:39 UTC (permalink / raw)
  To: kdj



Hello Friend

I Have a Proposal for your kindly contact me via:  emzong@outlook.com


Thank You.





________

ü Mielőtt kinyomtatja ezt az e-mailt, gondoljon a környezetre. P Please consider the environment before printing this email.
*******

Ezt az emailt a Websense ESG ellenőrizte a BKV Zrt. biztonsági szabályzata alapján. Nem található benne vírus.

^ permalink raw reply	[flat|nested] 414+ messages in thread
* Re:
@ 2017-05-03  6:23 H.A
  0 siblings, 0 replies; 414+ messages in thread
From: H.A @ 2017-05-03  6:23 UTC (permalink / raw)
  To: Recipients

With profound love in my heart, I Kindly Oblige your interest to very important proposal.. It is Truly Divine and require your utmost attention..........

S hlubokou láskou v mém srdci, Laskave jsem prinutit svuj zájem k návrhu .. Je velmi duležité, skutecne Divine a vyžadují vaši nejvyšší pozornost.

  Kontaktujte me prímo pres: helenaroberts99@gmail.com pro úplné podrobnosti.complete.


HELINA .A ROBERTS

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

^ permalink raw reply	[flat|nested] 414+ messages in thread
* (no subject)
@ 2017-04-28  8:20 Anatolij Gustschin
  2017-04-28  8:43 ` Linus Walleij
  0 siblings, 1 reply; 414+ messages in thread
From: Anatolij Gustschin @ 2017-04-28  8:20 UTC (permalink / raw)
  To: linus.walleij, gnurou; +Cc: andy.shevchenko, linux-gpio, linux-kernel

Subject: [PATCH v3] gpiolib: Add stubs for gpiod lookup table interface

Add stubs for gpiod_add_lookup_table() and gpiod_remove_lookup_table()
for the !GPIOLIB case to prevent build errors. Also add prototypes.

Signed-off-by: Anatolij Gustschin <agust@denx.de>
---
Changes in v3:
 - add stubs for !GPIOLIB case. Drop prototypes, these are
   already in gpio/machine.h

Changes in v2:
 - move gpiod_lookup_table out of #ifdef

 include/linux/gpio/consumer.h | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/include/linux/gpio/consumer.h b/include/linux/gpio/consumer.h
index 8f702fc..cf3fee2 100644
--- a/include/linux/gpio/consumer.h
+++ b/include/linux/gpio/consumer.h
@@ -41,6 +41,8 @@ enum gpiod_flags {
 			  GPIOD_FLAGS_BIT_DIR_VAL,
 };
 
+struct gpiod_lookup_table;
+
 #ifdef CONFIG_GPIOLIB
 
 /* Return the number of GPIOs associated with a device / function */
@@ -435,6 +437,12 @@ struct gpio_desc *devm_fwnode_get_index_gpiod_from_child(struct device *dev,
 	return ERR_PTR(-ENOSYS);
 }
 
+static inline
+void gpiod_add_lookup_table(struct gpiod_lookup_table *table) {}
+
+static inline
+void gpiod_remove_lookup_table(struct gpiod_lookup_table *table) {}
+
 #endif /* CONFIG_GPIOLIB */
 
 static inline
-- 
2.7.4

^ permalink raw reply related	[flat|nested] 414+ messages in thread
* RE:
@ 2017-02-23 15:09 Qin's Yanjun
  0 siblings, 0 replies; 414+ messages in thread
From: Qin's Yanjun @ 2017-02-23 15:09 UTC (permalink / raw)



How are you today and your family? I require your attention and honest
co-operation about some issues which i will really want to discuss with you
which.  Looking forward to read from you soon.  

Qin's


______________________________

Sky Silk, http://aknet.kz

^ permalink raw reply	[flat|nested] 414+ messages in thread
* Re:
@ 2017-01-07 14:47 Information
  0 siblings, 0 replies; 414+ messages in thread
From: Information @ 2017-01-07 14:47 UTC (permalink / raw)




Do you need loan? we offer all kinds of loan from minimum amount of $5,000 to maximum of $2,000,000 if you are interested contact us via: internationalloan09@gmail.com    with the information below:

Full Name:
Country:
Loan Amount:
Loan Duration:
Mobile phone number:
Sex:

Thanks,
Dr Scott.

^ permalink raw reply	[flat|nested] 414+ messages in thread
* re:
@ 2016-11-15  4:40 Apply
  0 siblings, 0 replies; 414+ messages in thread
From: Apply @ 2016-11-15  4:40 UTC (permalink / raw)
  To: Recipients

Do you need loan?we offer all kinds of loan from minimum amount of $5,000 to maximum of $2,000,000 if you are interested contact us via:internationalloanplc1@gmail.com  with the information below:
Full Name:
Country:
Loan Amount:
Loan Duration:
Mobile phone number:
Sex:
Thanks,
Dr Scott.

^ permalink raw reply	[flat|nested] 414+ messages in thread
* Re:
@ 2016-11-08 13:46 vaserman
  0 siblings, 0 replies; 414+ messages in thread
From: vaserman @ 2016-11-08 13:46 UTC (permalink / raw)
  To: info


--
I need your help

^ permalink raw reply	[flat|nested] 414+ messages in thread
* RE:
@ 2016-11-02  2:36 U
  0 siblings, 0 replies; 414+ messages in thread
From: U @ 2016-11-02  2:36 UTC (permalink / raw)
  To: info

[-- Attachment #1: Type: text/plain, Size: 24 bytes --]


-- 
UK NATIONAL LOTTERY

[-- Attachment #2: UK.jpg --]
[-- Type: , Size: 185835 bytes --]

^ permalink raw reply	[flat|nested] 414+ messages in thread
* Re:
@ 2016-07-21 21:50 Amit Jain
  0 siblings, 0 replies; 414+ messages in thread
From: Amit Jain @ 2016-07-21 21:50 UTC (permalink / raw)


Dear Esteemed Friend,

My name is Mr. Amit Jain, I double as the Group Chief Operations Officer Emaar Properties and Chief Executive Officer Emaar Dubai. Let me know the possibilities of setting up a private investment in your country as I am interested in your region. I have interest in Real Estate, Industry, Energy and Agriculture.

Follow the link to know more about our company profile: https://www.emaar.com/en/who-we-are/leadership/principal-officers.aspx

I expect to get a response from you to enable us discuss more.

Regards,
Mr. Amit Jain.
P.O. Box 120360,
Group Chief Operations Officer
Emaar Properties PJSC

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

^ permalink raw reply	[flat|nested] 414+ messages in thread
* Re:
@ 2016-07-04 15:47 Mr. Bun Sam
  0 siblings, 0 replies; 414+ messages in thread
From: Mr. Bun Sam @ 2016-07-04 15:47 UTC (permalink / raw)
  To: linux-kernel

Hi,

I work with one of the major banks in Cambodia as the director of audit. I have a proposal for you, a very urgent and quick business that will be completed in 12 working days. I have just discovered documents relating to funds belonging to a deceased client of our bank,

I went through all the related documents to the funds and I discovered no listed next of kin to inherit the funds which has been in our bank for more than 7 years now. I need your cooperation in getting the funds, I have the power to list you as the beneficiary of the funds and have the funds transferred to you.

If you are interested, do get back to me so I can provide you with the full details.

Regards
Bun Sam.

^ permalink raw reply	[flat|nested] 414+ messages in thread
* Re:
@ 2016-07-02 11:30 Mr. Bun Sam
  0 siblings, 0 replies; 414+ messages in thread
From: Mr. Bun Sam @ 2016-07-02 11:30 UTC (permalink / raw)
  To: linux-kernel

Hi,

I work with one of the major banks in Cambodia as the director of audit. I have a proposal for you, a very urgent and quick business that will be completed in 12 working days. I have just discovered documents relating to funds belonging to a deceased client of our bank,

I went through all the related documents to the funds and I discovered no listed next of kin to inherit the funds which has been in our bank for more than 7 years now. I need your cooperation in getting the funds, I have the power to list you as the beneficiary of the funds and have the funds transferred to you.

If you are interested, do get back to me so I can provide you with the full details.

Regards
Bun Sam.

^ permalink raw reply	[flat|nested] 414+ messages in thread
* Re:
@ 2016-06-27  8:24 Fidelity Loans
  0 siblings, 0 replies; 414+ messages in thread
From: Fidelity Loans @ 2016-06-27  8:24 UTC (permalink / raw)
  To: Recipients

Loan Offer at 3%, Feel Free to REPLY back to us for more info

^ permalink raw reply	[flat|nested] 414+ messages in thread
* (no subject)
@ 2016-02-10 14:36 Petr Mladek
  2016-02-10 14:44 ` Steven Rostedt
  0 siblings, 1 reply; 414+ messages in thread
From: Petr Mladek @ 2016-02-10 14:36 UTC (permalink / raw)
  To: Denys Vlasenko
  Cc: linux-kernel, srostedt, Steven Rostedt, Tejun Heo, Peter Hurley,
	Jan Kara, Sergey Senozhatsky, Andrew Morton, Kyle McMartin,
	KY Srinivasan, Dave Jones, Calvin Owens

Bcc: 
Subject: Re: [PATCH] printk: avoid livelock if another CPU printks
 continuously
Reply-To: 
In-Reply-To: <1454963703-20433-1-git-send-email-dvlasenk@redhat.com>

On Mon 2016-02-08 21:35:03, Denys Vlasenko wrote:
> At the end of each printk(), kernel attempts to take console_sem.
> If this succeeds, it feeds buffered message data to console devices
> until there is nothing left, and releases console_sem:
> 
>         if (console_trylock_for_printk(this_cpu))
>                 console_unlock();
> 
> The livelock exists because code in console_unlock() has no
> limit on the amount of buffered data it would process under
> console_sem. This is bad if printk() was called with IRQs disabled.
> 
> This patch makes console_unlock() release console_sem after 5
> iterations, which usually amounts to 5 lines of printk messages,
> and give other printk'ing CPUs a chance to acquire console_sem.
> 
> If some CPU grabs it, console_unlock() finishes.
> If no one takes the semaphore, console_unlock() re-acquires it
> and loops back for another cycle of console output.
> 
> This seems to be a hard-to-trigger, but long-existing problem:

Yup, and there are more people trying to handle this. I add some
of them into CC.

Sadly, the problem is much more complicated that it looks. Jan Kara
(jack) has already provided many possible solutions that were not
accepted. The last one can be seen at
http://thread.gmane.org/gmane.linux.kernel/2105183/focus=2113787

See below some comments to your approach.

> Signed-off-by: Denys Vlasenko <dvlasenk@redhat.com>
> CC: linux-kernel@vger.kernel.org
> CC: srostedt@redhat.com
> CC: Steven Rostedt <rostedt@goodmis.org>
> CC: Tejun Heo <tj@kernel.org>
> CC: Peter Hurley <peter@hurleysoftware.com>
> ---
>  kernel/printk/printk.c | 25 +++++++++++++++++++++++++
>  1 file changed, 25 insertions(+)
> 
> diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
> index c963ba5..ca4f9d55 100644
> --- a/kernel/printk/printk.c
> +++ b/kernel/printk/printk.c
> @@ -2235,6 +2235,7 @@ void console_unlock(void)
>  	unsigned long flags;
>  	bool wake_klogd = false;
>  	bool do_cond_resched, retry;
> +	unsigned cnt;
>  
>  	if (console_suspended) {
>  		up_console_sem();
> @@ -2257,6 +2258,7 @@ void console_unlock(void)
>  	/* flush buffered message fragment immediately to console */
>  	console_cont_flush(text, sizeof(text));
>  again:
> +	cnt = 5;
>  	for (;;) {
>  		struct printk_log *msg;
>  		size_t ext_len = 0;
> @@ -2284,6 +2286,9 @@ skip:
>  		if (console_seq == log_next_seq)
>  			break;
>  
> +		if (--cnt == 0)
> +			break;	/* Someone else printk's like crazy */
> +
>  		msg = log_from_idx(console_idx);
>  		if (msg->flags & LOG_NOCONS) {
>  			/*
> @@ -2350,6 +2355,26 @@ skip:
>  	if (retry && console_trylock())
>  		goto again;
>  
> +	if (cnt == 0) {
> +		/*
> +		 * Other CPU(s) printk like crazy, filling log_buf[].
> +		 * Try to get rid of the "honor" of servicing their data:
> +		 * give _them_ time to grab console_sem and start working.
> +		 */
> +		cnt = 9999;
> +		while (--cnt != 0) {
> +			cpu_relax();
> +			if (console_seq == log_next_seq) {

This condition is true when all available messages are printed to
the console. It means that there is nothing to do at all. It is
quite late. A much better solution would be to store console_seq
to a local variable and check it is being modified by an other CPU.


> +				/* Good, other CPU entered "for(;;)" loop */
> +				goto out;
> +			}
> +		}
> +		/* No one seems to be willing to take it... */
> +		if (console_trylock())
> +			goto again; /* we took it */
> +		/* Nope, someone else holds console_sem! Good */

The cycle gives a big chance other CPUs to enter console_unlock().
It means that more CPUs might end up in the above busy cycle.

It gives a chance to move the printing to another CPU. It likely
slows down the flood of messages because the producer end up
here as well.

So, it probably works but the performance is far from optimal.
Many CPUs might end up doing nothing. I am afraid that this is
not the right way to go.

Best Regards,
Petr

^ permalink raw reply	[flat|nested] 414+ messages in thread
* re:
@ 2016-02-08  3:11 Qatar Foundation
  0 siblings, 0 replies; 414+ messages in thread
From: Qatar Foundation @ 2016-02-08  3:11 UTC (permalink / raw)
  To: Recipients

Dear Beneficiary,
You have been selected to receive €950,000.00 EURO as charity donations
aid of the Qatar Foundation. Reply back for
information and claims.
Reply to: w.d1966@gmx.com
Yours sincerely,
Mr. Rashid Al-Naimi.
The Chief Executive Officer of
Qatar Foundation Endowment.

^ permalink raw reply	[flat|nested] 414+ messages in thread
* Re:
@ 2016-01-26 20:52 Ms Nadia Mohammed
  0 siblings, 0 replies; 414+ messages in thread
From: Ms Nadia Mohammed @ 2016-01-26 20:52 UTC (permalink / raw)
  To: Recipients

I hope this letter find you in good health , I'm Ms Nadia Mohammed , I have a project i want to bring to you and i want you to reply me and help me discuss this proposal. please reply to my personal email at :   nadiamohammed099@gmail.com

^ permalink raw reply	[flat|nested] 414+ messages in thread
* Re:
@ 2016-01-15  2:39 Trust Guarantee
  0 siblings, 0 replies; 414+ messages in thread
From: Trust Guarantee @ 2016-01-15  2:39 UTC (permalink / raw)


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain;charset=iso-88591-1, Size: 496 bytes --]




Sie benötigen dringend Darlehen? Wir geben Darlehen an interessierte
Einzelpersonen, die versuchen, Darlehen mit Treu und Glauben. Sind Sie
ernsthaft brauchen dringend Darlehen? dann sind Sie an der richtigen
Stelle. Wir geben Business-Darlehen, persönliche Darlehen, kontaktieren
Sie uns für Ihr Darlehen beantragen, um Ihre Nachfrage zu befriedigen und
per E-Mail aus Finanz problem.contact uns heute fest:
trustguarantee1@gmail.com
Dank wie wir erwarte Ihre Antwort
Vertrauensgarantie Loan

^ permalink raw reply	[flat|nested] 414+ messages in thread
* Re:
@ 2015-12-18 11:50 
  0 siblings, 0 replies; 414+ messages in thread
From:  @ 2015-12-18 11:50 UTC (permalink / raw)
  To: Recipients

I thought you would have responded by now?

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus


^ permalink raw reply	[flat|nested] 414+ messages in thread
* Re:
@ 2015-12-11  9:30 Матвеева Руслана
  0 siblings, 0 replies; 414+ messages in thread
From: Матвеева Руслана @ 2015-12-11  9:30 UTC (permalink / raw)
  To: linux-kernel

Приветствую Вас.

Заказывали ли Вы, рекламу по почтовым майл адресам?

vip.tacanuur48@mail.ru 


^ permalink raw reply	[flat|nested] 414+ messages in thread
[parent not found: <D0613EBE33E8FD439137DAA95CCF59555B7A5A4D@MGCCCMAIL2010-5.mgccc.cc.ms.us>]
[parent not found: <CA+47Ykimr0d9cR35aWoCtm8JoXUYjKFXL0HJ-c=EE_suTAPR8w@mail.gmail.com>]
* Re:
@ 2015-11-07 16:48 Mohammed
  0 siblings, 0 replies; 414+ messages in thread
From: Mohammed @ 2015-11-07 16:48 UTC (permalink / raw)
  To: Recipients

Message from Saudi Arabia Prince Alwaleed bin Talal for his charity donation and You have been selected as recipient/benefactor for $5Million Dollars from Alwaleed Philanthropic Foundation Grant.for more information contact Via email  ally00256@yandex.com

Thanks

Ally Mohammed

Please, reply should go to ally00256@yandex.com

^ permalink raw reply	[flat|nested] 414+ messages in thread
* RE:
@ 2015-10-29  2:40 
  0 siblings, 0 replies; 414+ messages in thread
From:  @ 2015-10-29  2:40 UTC (permalink / raw)
  To: Recipients

Hello,

I am Major. Alan Edward, in the military unit here in Afghanistan and i need an urgent assistance with someone i can trust,It's risk free and legal.

---
This email has been checked for viruses by Avast antivirus software.
http://www.avast.com


^ permalink raw reply	[flat|nested] 414+ messages in thread
* RE:
@ 2015-10-23 14:46 MajorAlan
  0 siblings, 0 replies; 414+ messages in thread
From: MajorAlan @ 2015-10-23 14:46 UTC (permalink / raw)
  To: Recipients

I am in the military unit here in Afghanistan,we have some amount of funds that we want to move out of the country.My partners and I need a good partner someone we can trust. It is risk free and legal. Reply to this email   majoralan.edward@gmx.com

Regards,
Major. Alan Edward

^ permalink raw reply	[flat|nested] 414+ messages in thread
* Re:
@ 2015-10-21  2:26 Mohammed
  0 siblings, 0 replies; 414+ messages in thread
From: Mohammed @ 2015-10-21  2:26 UTC (permalink / raw)
  To: Recipients

Message from Saudi Arabia Prince Alwaleed bin Talal for his charity donation and You have been selected as recipient/benefactor for $5Million Dollars from Alwaleed Philanthropic Foundation Grant.for more information contact Via email  ally00256@yandex.com

Thanks

Ally Mohammed

Please, reply should go to ally00256@yandex.com

^ permalink raw reply	[flat|nested] 414+ messages in thread
* Re ...
@ 2015-10-08  8:30 BRGF
  0 siblings, 0 replies; 414+ messages in thread
From: BRGF @ 2015-10-08  8:30 UTC (permalink / raw)
  To: Recipients

Apply for your urgent financial help today and have it in your bank account within 24 hours. For more information, contact us with your interest through the form below; 

Full Name:
Address:
Country:
Loan Amount:
Duration:
Purpose of Loan:
Phone Number:

We hope to hear from you soonest. 

Hamon Hassan
operations manager.
©2015 BRGF & Co Inc.
All Rights Reserved.

^ permalink raw reply	[flat|nested] 414+ messages in thread
* Re:
@ 2015-09-01 16:06 Zariya
  0 siblings, 0 replies; 414+ messages in thread
From: Zariya @ 2015-09-01 16:06 UTC (permalink / raw)
  To: Recipients

Help me and my 2 kids here in Syria We will share the 6,600,000 USD
I have here with you for your help, sorry to mention it
we want to leave Syria, put the kids in school and buy a new home
You will give us guidance when we arrive Their father died in the chemical weapon airstrike
I will send you our family pictures and more details as I read from you

Yours

ZariyaHelp me and my 2 kids here in Syria We will share the 6,600,000 USD
I have here with you for your help, sorry to mention it
we want to leave Syria, put the kids in school and buy a new home
You will give us guidance when we arrive Their father died in the chemical weapon airstrike
I will send you our family pictures and more details as I read from you

Yours

Zariya

^ permalink raw reply	[flat|nested] 414+ messages in thread
* (no subject)
@ 2015-09-01 14:14 Mika Penttilä
  2015-09-01 15:22 ` Fabio Estevam
  0 siblings, 1 reply; 414+ messages in thread
From: Mika Penttilä @ 2015-09-01 14:14 UTC (permalink / raw)
  To: linux-kernel, linux-arm-kernel, edubezval

This one causes imx6q with debug uart connected to "schedule while
atomic" endlessly :


9e7b399d6528eac33a6fbfceb2b92af209c3454d is the first bad commit
commit 9e7b399d6528eac33a6fbfceb2b92af209c3454d
Author: Eduardo Valentin <edubezval@gmail.com>
Date:   Tue Aug 11 10:21:20 2015 -0700

    serial: imx: remove unbalanced clk_prepare

    The current code attempts to prepare clk_per and clk_ipg
    before using the device. However, the result is an extra
    prepare call on each clock. Here is the output of uart
    clocks (only uart enabled and used as console):

    $  grep uart /sys/kernel/debug/clk/clk_summary
     uart_serial           1            2    80000000          0 0
           uart           1            2    66000000          0 0

    This patch balances the calls of prepares. The result is:

    $  grep uart /sys/kernel/debug/clk/clk_summary
     uart_serial           1            1    80000000          0 0
           uart           1            1    66000000          0 0

    Cc: Fabio Estevam <festevam@gmail.com>
    Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Cc: Jiri Slaby <jslaby@suse.com>
    Cc: linux-serial@vger.kernel.org
    Cc: linux-pm@vger.kernel.org
    Cc: linux-kernel@vger.kernel.org
    Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

^ permalink raw reply	[flat|nested] 414+ messages in thread
* Re:
@ 2015-09-01 12:01 Zariya
  0 siblings, 0 replies; 414+ messages in thread
From: Zariya @ 2015-09-01 12:01 UTC (permalink / raw)
  To: Recipients

Help me and my 2 kids here in Syria We will share the 6,600,000 USD
I have here with you for your help, sorry to mention it
we want to leave Syria, put the kids in school and buy a new home
You will give us guidance when we arrive Their father died in the chemical weapon airstrike
I will send you our family pictures and more details as I read from you

Yours

ZariyaHelp me and my 2 kids here in Syria We will share the 6,600,000 USD
I have here with you for your help, sorry to mention it
we want to leave Syria, put the kids in school and buy a new home
You will give us guidance when we arrive Their father died in the chemical weapon airstrike
I will send you our family pictures and more details as I read from you

Yours

Zariya

^ permalink raw reply	[flat|nested] 414+ messages in thread
* Re:
@ 2015-08-19 13:01 christain147
  0 siblings, 0 replies; 414+ messages in thread
From: christain147 @ 2015-08-19 13:01 UTC (permalink / raw)
  To: Recipients

Good day,hoping you read this email and respond to me in good time.I do not intend to solicit for funds but  your time and energy in using my own resources to assist the less privileged.I am medically confined at the moment hence I request your indulgence.
I will give you a comprehensive brief once I hear from you.

Please forward your response to my private email address:
gudworks104@yahoo.com

Thanks and reply.

Robert Grondahl

^ permalink raw reply	[flat|nested] 414+ messages in thread
* Re:
@ 2015-07-24 10:34 Mrs Nadia  Mohammed 
  0 siblings, 0 replies; 414+ messages in thread
From: Mrs Nadia  Mohammed  @ 2015-07-24 10:34 UTC (permalink / raw)


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=utf-8, Size: 453 bytes --]




السلام عليكم انا مدام نادية محمد غانم من فلسطين و اريد منك ان تساعدنى لاننى لدى مشروع اريد ان اعرضه اليك  لذا ارجو منك التواصل معى على هذا الايميل 

nadiamghanem07@gmail.comÿôèº{.nÇ+‰·Ÿ®‰­†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a­¢f£¢·hšïêÿ‘êçz_è®\x03(­éšŽŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨è­Ú&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥

^ permalink raw reply	[flat|nested] 414+ messages in thread
[parent not found: <CACy=+DtdZOUT4soNZ=zz+_qhCfM=C8Oa0D5gjRC7QM3nYi4oEw@mail.gmail.com>]
[parent not found: <CAHxZcryF7pNoENh8vpo-uvcEo5HYA5XgkZFWrLEHM5Hhf5ay+Q@mail.gmail.com>]
[parent not found: <E1Yz4NQ-0000Cw-B5@feisty.vs19.net>]
* Re:
@ 2015-05-22  0:17 kontakt
  0 siblings, 0 replies; 414+ messages in thread
From: kontakt @ 2015-05-22  0:17 UTC (permalink / raw)
  To: Recipients

Teraz mozesz uzyskac kredyt w wysokosci 2% za uniewaznic i dostac do 40 lat lub wiecej, aby splacic. Nie naleza do kredytów krótkoterminowych, które sprawiaja, ze zwróci sie w kilka tygodni lub miesiecy. Nasza oferta obejmuje; * Refinansowanie * Home Improvement * Kredyty samochodowe * Konsolidacja zadluzenia * Linia kredytowa * Druga hipoteczny * Biznes Pozyczki * Pozyczki Personal

  Zdobadz pieniadze potrzebne dzis z duza iloscia czasu, aby dokonac platnosci powrotem. Aby zastosowac, aby wyslac wszystkie pytania lub zaproszenia fwfshelpdesk@gmail.com: + 1- 435-241-5945

************************************************************
Now you can get a loan at 2% per annul and get up to 40 years or more to pay it back. Don't fall for the short term loans that make you pay back in weeks or months. Our offer include; *Refinance *Home Improvement *Auto Loans *Debt Consolidation*Line of Credit *Second Mortgage *Business Loans*Personal Loans

 Get the money you need today with plenty of time to make the payments back. To apply, send all inquiries to fwfshelpdesk@gmail.com or call : + 1- 435-241-5945

---
This email is free from viruses and malware because avast! Antivirus protection is active.
http://www.avast.com


^ permalink raw reply	[flat|nested] 414+ messages in thread
[parent not found: <90BA5B564A2E4B4782C6F4398C32EE104E54369A@NHS-PCLI-MBC003.AD1.NHS.NET>]
[parent not found: <9E5F73AAFC185F49B0D37FE62E65D6C20724A9D8@XSERVER23A.campus.tue.nl>]
* Re:
@ 2015-04-21  7:43 Galaxy Darlehen Firma
  0 siblings, 0 replies; 414+ messages in thread
From: Galaxy Darlehen Firma @ 2015-04-21  7:43 UTC (permalink / raw)


-- 

Benötigen Sie dringend Darlehen? Wir geben Darlehen an interessierten
Einzelpersonen, die Darlehen mit gutem Glauben suchen. Sind Sie
ernsthaft brauchen eine dringende Darlehen? dann sind Sie bei uns
richtig. Wir geben Business-Darlehen, Privatkredit, kontaktieren Sie
uns für Ihren Darlehensantrag auf Ihre Nachfrage und durch finanzielle
problem.contact uns heute per e-Mail: galaxyfunds1@gmail.com

Vielen Dank wie wir Ihre Antwort erwarten
Galaxy Darlehen Firma

^ permalink raw reply	[flat|nested] 414+ messages in thread
[parent not found: <CAONCqDfSP9DSWwPSDqz4NS6YHmzwMo=6VnRURRAJZLeGE_QKYA@mail.gmail.com>]
* Re:
@ 2015-04-01 21:56 Globale Trust Company
  0 siblings, 0 replies; 414+ messages in thread
From: Globale Trust Company @ 2015-04-01 21:56 UTC (permalink / raw)


-- 
Sind Sie ein Unternehmer Mann oder eine Frau? Sind Sie in finanziellen
Schwierigkeiten, oder haben Sie finanzielle Mittel benötigen, um Ihr
eigenes Unternehmen gründen? Brauchen Sie noch einen Autokredit? Sie
haben einen niedrigen Kredit-Score und Sie finden es schwierig, ein
Darlehen von lokalen Banken und anderen Finanzinstituten zu bekommen?
Sie benötigen ein Darlehen aus irgendeinem Grund, Gründe, wie .:
a) persönliche Darlehen, Ausbau des Geschäfts.
b) Unternehmertum und Bildung.
(c) Schuldenkonsolidierung).
     Wir bieten Darlehen zu einem sehr niedrigen Zinssatz und ohne
Bonitätsprüfung, bieten wir persönliche Darlehen,
Schuldenkonsolidierung, Venture Capital, Business Education Kredit,
Kreditwohnungsbaudarlehen oder "Kredit aus anderen Gründen !."
Hinweis: Jeder interessierte Bewerber sollte uns auf diese E-Mail für
mehr kontaktieren
Informationen zu unserem Kredit-Programm.

Name: Globale Trust Company
E-Mail: globaltrust732@gmail.com

Wir danken Ihnen für Ihr Verständnis, die darauf warten, von Ihnen zu hören.

^ permalink raw reply	[flat|nested] 414+ messages in thread
* (no subject)
@ 2015-03-04 10:29 Quentin Lambert
  2015-03-04 10:32 ` Quentin Lambert
  0 siblings, 1 reply; 414+ messages in thread
From: Quentin Lambert @ 2015-03-04 10:29 UTC (permalink / raw)
  To: Greg Kroah-Hartman; +Cc: kernel-janitors, devel, linux-kernel

Bcc: 
Subject: [PATCH 1/2] staging: rts5208: Convert non-returned local variable to
 boolean when relevant
Reply-To: 

This patch was produced using Coccinelle. A simplified version of the
semantic patch is:

@r exists@
identifier f;
local idexpression u8 x;
identifier xname;
@@

f(...) {
...when any
(
  x@xname = 1;
|
  x@xname = 0;
)
...when any
}

@bad exists@
identifier r.f;
local idexpression u8 r.x
expression e1 != {0, 1}, e2;
@@

f(...) {
...when any
(
  x = e1;
|
  x + e2
)
...when any
}

@depends on !bad@
identifier r.f;
local idexpression u8 r.x;
identifier r.xname;
@@

f(...) {
...
++ bool xname;
- int xname;
<...
(
  x =
- 1
+ true
|
  x =
- -1
+ false
)
...>

}

Signed-off-by: Quentin Lambert <lambert.quentin@gmail.com>
---
 drivers/staging/rts5208/ms.c        | 14 +++---
 drivers/staging/rts5208/rtsx_chip.c | 56 ++++++++++++-----------
 drivers/staging/rts5208/rtsx_scsi.c | 38 +++++++++-------
 drivers/staging/rts5208/sd.c        | 88 +++++++++++++++++++------------------
 4 files changed, 105 insertions(+), 91 deletions(-)

diff --git a/drivers/staging/rts5208/ms.c b/drivers/staging/rts5208/ms.c
index a47a191..050bc47 100644
--- a/drivers/staging/rts5208/ms.c
+++ b/drivers/staging/rts5208/ms.c
@@ -1560,7 +1560,8 @@ static int ms_copy_page(struct rtsx_chip *chip, u16 old_blk, u16 new_blk,
 		u16 log_blk, u8 start_page, u8 end_page)
 {
 	struct ms_info *ms_card = &(chip->ms_card);
-	int retval, rty_cnt, uncorrect_flag = 0;
+	bool uncorrect_flag = false;
+	int retval, rty_cnt;
 	u8 extra[MS_EXTRA_SIZE], val, i, j, data[16];
 
 	dev_dbg(rtsx_dev(chip), "Copy page from 0x%x to 0x%x, logical block is 0x%x\n",
@@ -1642,10 +1643,10 @@ static int ms_copy_page(struct rtsx_chip *chip, u16 old_blk, u16 new_blk,
 			if (val & INT_REG_ERR) {
 				retval = ms_read_status_reg(chip);
 				if (retval != STATUS_SUCCESS) {
-					uncorrect_flag = 1;
+					uncorrect_flag = true;
 					dev_dbg(rtsx_dev(chip), "Uncorrectable error\n");
 				} else {
-					uncorrect_flag = 0;
+					uncorrect_flag = false;
 				}
 
 				retval = ms_transfer_tpc(chip,
@@ -2187,7 +2188,8 @@ static int ms_build_l2p_tbl(struct rtsx_chip *chip, int seg_no)
 {
 	struct ms_info *ms_card = &(chip->ms_card);
 	struct zone_entry *segment;
-	int retval, table_size, disable_cnt, defect_flag, i;
+	bool defect_flag;
+	int retval, table_size, disable_cnt, i;
 	u16 start, end, phy_blk, log_blk, tmp_blk;
 	u8 extra[MS_EXTRA_SIZE], us1, us2;
 
@@ -2236,10 +2238,10 @@ static int ms_build_l2p_tbl(struct rtsx_chip *chip, int seg_no)
 
 	for (phy_blk = start; phy_blk < end; phy_blk++) {
 		if (disable_cnt) {
-			defect_flag = 0;
+			defect_flag = false;
 			for (i = 0; i < segment->disable_count; i++) {
 				if (phy_blk == segment->defect_list[i]) {
-					defect_flag = 1;
+					defect_flag = true;
 					break;
 				}
 			}
diff --git a/drivers/staging/rts5208/rtsx_chip.c b/drivers/staging/rts5208/rtsx_chip.c
index 9593d81..35fa19d 100644
--- a/drivers/staging/rts5208/rtsx_chip.c
+++ b/drivers/staging/rts5208/rtsx_chip.c
@@ -153,22 +153,22 @@ static int rtsx_pre_handle_sdio_old(struct rtsx_chip *chip)
 static int rtsx_pre_handle_sdio_new(struct rtsx_chip *chip)
 {
 	u8 tmp;
-	int sw_bypass_sd = 0;
+	bool sw_bypass_sd = false;
 	int retval;
 
 	if (chip->driver_first_load) {
 		if (CHECK_PID(chip, 0x5288)) {
 			RTSX_READ_REG(chip, 0xFE5A, &tmp);
 			if (tmp & 0x08)
-				sw_bypass_sd = 1;
+				sw_bypass_sd = true;
 		} else if (CHECK_PID(chip, 0x5208)) {
 			RTSX_READ_REG(chip, 0xFE70, &tmp);
 			if (tmp & 0x80)
-				sw_bypass_sd = 1;
+				sw_bypass_sd = true;
 		}
 	} else {
 		if (chip->sdio_in_charge)
-			sw_bypass_sd = 1;
+			sw_bypass_sd = true;
 	}
 	dev_dbg(rtsx_dev(chip), "chip->sdio_in_charge = %d\n",
 		chip->sdio_in_charge);
@@ -501,13 +501,14 @@ nextcard:
 
 static inline int check_sd_speed_prior(u32 sd_speed_prior)
 {
-	int i, fake_para = 0;
+	bool fake_para = false;
+	int i;
 
 	for (i = 0; i < 4; i++) {
 		u8 tmp = (u8)(sd_speed_prior >> (i*8));
 
 		if ((tmp < 0x01) || (tmp > 0x04)) {
-			fake_para = 1;
+			fake_para = true;
 			break;
 		}
 	}
@@ -517,13 +518,14 @@ static inline int check_sd_speed_prior(u32 sd_speed_prior)
 
 static inline int check_sd_current_prior(u32 sd_current_prior)
 {
-	int i, fake_para = 0;
+	bool fake_para = false;
+	int i;
 
 	for (i = 0; i < 4; i++) {
 		u8 tmp = (u8)(sd_current_prior >> (i*8));
 
 		if (tmp > 0x03) {
-			fake_para = 1;
+			fake_para = true;
 			break;
 		}
 	}
@@ -784,31 +786,31 @@ static inline void rtsx_blink_led(struct rtsx_chip *chip)
 
 static void rtsx_monitor_aspm_config(struct rtsx_chip *chip)
 {
-	int maybe_support_aspm, reg_changed;
+	bool reg_changed, maybe_support_aspm;
 	u32 tmp = 0;
 	u8 reg0 = 0, reg1 = 0;
 
-	maybe_support_aspm = 0;
-	reg_changed = 0;
+	maybe_support_aspm = false;
+	reg_changed = false;
 	rtsx_read_config_byte(chip, LCTLR, &reg0);
 	if (chip->aspm_level[0] != reg0) {
-		reg_changed = 1;
+		reg_changed = true;
 		chip->aspm_level[0] = reg0;
 	}
 	if (CHK_SDIO_EXIST(chip) && !CHK_SDIO_IGNORED(chip)) {
 		rtsx_read_cfg_dw(chip, 1, 0xC0, &tmp);
 		reg1 = (u8)tmp;
 		if (chip->aspm_level[1] != reg1) {
-			reg_changed = 1;
+			reg_changed = true;
 			chip->aspm_level[1] = reg1;
 		}
 
 		if ((reg0 & 0x03) && (reg1 & 0x03))
-			maybe_support_aspm = 1;
+			maybe_support_aspm = true;
 
 	} else {
 		if (reg0 & 0x03)
-			maybe_support_aspm = 1;
+			maybe_support_aspm = true;
 	}
 
 	if (reg_changed) {
@@ -835,7 +837,7 @@ void rtsx_polling_func(struct rtsx_chip *chip)
 #ifdef SUPPORT_SD_LOCK
 	struct sd_info *sd_card = &chip->sd_card;
 #endif
-	int ss_allowed;
+	bool ss_allowed;
 
 	if (rtsx_chk_stat(chip, RTSX_STAT_SUSPEND))
 		return;
@@ -887,21 +889,21 @@ void rtsx_polling_func(struct rtsx_chip *chip)
 	rtsx_init_cards(chip);
 
 	if (chip->ss_en) {
-		ss_allowed = 1;
+		ss_allowed = true;
 
 		if (CHECK_PID(chip, 0x5288)) {
-			ss_allowed = 0;
+			ss_allowed = false;
 		} else {
 			if (CHK_SDIO_EXIST(chip) && !CHK_SDIO_IGNORED(chip)) {
 				u32 val;
 
 				rtsx_read_cfg_dw(chip, 1, 0x04, &val);
 				if (val & 0x07)
-					ss_allowed = 0;
+					ss_allowed = false;
 			}
 		}
 	} else {
-		ss_allowed = 0;
+		ss_allowed = false;
 	}
 
 	if (ss_allowed && !chip->sd_io) {
@@ -1358,7 +1360,8 @@ int rtsx_read_cfg_seq(struct rtsx_chip *chip, u8 func, u16 addr, u8 *buf,
 
 int rtsx_write_phy_register(struct rtsx_chip *chip, u8 addr, u16 val)
 {
-	int i, finished = 0;
+	bool finished = false;
+	int i;
 	u8 tmp;
 
 	RTSX_WRITE_REG(chip, PHYDATA0, 0xFF, (u8)val);
@@ -1369,7 +1372,7 @@ int rtsx_write_phy_register(struct rtsx_chip *chip, u8 addr, u16 val)
 	for (i = 0; i < 100000; i++) {
 		RTSX_READ_REG(chip, PHYRWCTL, &tmp);
 		if (!(tmp & 0x80)) {
-			finished = 1;
+			finished = true;
 			break;
 		}
 	}
@@ -1382,7 +1385,8 @@ int rtsx_write_phy_register(struct rtsx_chip *chip, u8 addr, u16 val)
 
 int rtsx_read_phy_register(struct rtsx_chip *chip, u8 addr, u16 *val)
 {
-	int i, finished = 0;
+	bool finished = false;
+	int i;
 	u16 data = 0;
 	u8 tmp;
 
@@ -1392,7 +1396,7 @@ int rtsx_read_phy_register(struct rtsx_chip *chip, u8 addr, u16 *val)
 	for (i = 0; i < 100000; i++) {
 		RTSX_READ_REG(chip, PHYRWCTL, &tmp);
 		if (!(tmp & 0x80)) {
-			finished = 1;
+			finished = true;
 			break;
 		}
 	}
@@ -1615,7 +1619,7 @@ void rtsx_exit_ss(struct rtsx_chip *chip)
 int rtsx_pre_handle_interrupt(struct rtsx_chip *chip)
 {
 	u32 status, int_enable;
-	int exit_ss = 0;
+	bool exit_ss = false;
 #ifdef SUPPORT_OCP
 	u32 ocp_int = 0;
 
@@ -1625,7 +1629,7 @@ int rtsx_pre_handle_interrupt(struct rtsx_chip *chip)
 	if (chip->ss_en) {
 		chip->ss_counter = 0;
 		if (rtsx_get_stat(chip) == RTSX_STAT_SS) {
-			exit_ss = 1;
+			exit_ss = true;
 			rtsx_exit_L1(chip);
 			rtsx_set_stat(chip, RTSX_STAT_RUN);
 		}
diff --git a/drivers/staging/rts5208/rtsx_scsi.c b/drivers/staging/rts5208/rtsx_scsi.c
index 42645834..a00ba21 100644
--- a/drivers/staging/rts5208/rtsx_scsi.c
+++ b/drivers/staging/rts5208/rtsx_scsi.c
@@ -39,7 +39,8 @@ void scsi_show_command(struct rtsx_chip *chip)
 {
 	struct scsi_cmnd *srb = chip->srb;
 	char *what = NULL;
-	int unknown_cmd = 0, len;
+	bool unknown_cmd = false;
+	int len;
 
 	switch (srb->cmnd[0]) {
 	case TEST_UNIT_READY:
@@ -310,7 +311,8 @@ void scsi_show_command(struct rtsx_chip *chip)
 		what = "Realtek's vendor command";
 		break;
 	default:
-		what = "(unknown command)"; unknown_cmd = 1;
+		what = "(unknown command)";
+		unknown_cmd = true;
 		break;
 	}
 
@@ -485,7 +487,7 @@ static int inquiry(struct scsi_cmnd *srb, struct rtsx_chip *chip)
 	unsigned char sendbytes;
 	unsigned char *buf;
 	u8 card = get_lun_card(chip, lun);
-	int pro_formatter_flag = 0;
+	bool pro_formatter_flag = false;
 	unsigned char inquiry_buf[] = {
 		QULIFIRE|DRCT_ACCESS_DEV,
 		RMB_DISC|0x0D,
@@ -520,7 +522,7 @@ static int inquiry(struct scsi_cmnd *srb, struct rtsx_chip *chip)
 	if (chip->mspro_formatter_enable)
 #endif
 		if (!card || (card == MS_CARD))
-			pro_formatter_flag = 1;
+			pro_formatter_flag = true;
 
 	if (pro_formatter_flag) {
 		if (scsi_bufflen(srb) < 56)
@@ -663,7 +665,7 @@ static void ms_mode_sense(struct rtsx_chip *chip, u8 cmd,
 	struct ms_info *ms_card = &(chip->ms_card);
 	int sys_info_offset;
 	int data_size = buf_len;
-	int support_format = 0;
+	bool support_format = false;
 	int i = 0;
 
 	if (cmd == MODE_SENSE) {
@@ -684,10 +686,10 @@ static void ms_mode_sense(struct rtsx_chip *chip, u8 cmd,
 	/* Medium Type Code */
 	if (check_card_ready(chip, lun)) {
 		if (CHK_MSXC(ms_card)) {
-			support_format = 1;
+			support_format = true;
 			buf[i++] = 0x40;
 		} else if (CHK_MSPRO(ms_card)) {
-			support_format = 1;
+			support_format = true;
 			buf[i++] = 0x20;
 		} else {
 			buf[i++] = 0x10;
@@ -755,7 +757,7 @@ static int mode_sense(struct scsi_cmnd *srb, struct rtsx_chip *chip)
 	unsigned int lun = SCSI_LUN(srb);
 	unsigned int dataSize;
 	int status;
-	int pro_formatter_flag;
+	bool pro_formatter_flag;
 	unsigned char pageCode, *buf;
 	u8 card = get_lun_card(chip, lun);
 
@@ -767,20 +769,20 @@ static int mode_sense(struct scsi_cmnd *srb, struct rtsx_chip *chip)
 	}
 #endif
 
-	pro_formatter_flag = 0;
+	pro_formatter_flag = false;
 	dataSize = 8;
 #ifdef SUPPORT_MAGIC_GATE
 	if ((chip->lun2card[lun] & MS_CARD)) {
 		if (!card || (card == MS_CARD)) {
 			dataSize = 108;
 			if (chip->mspro_formatter_enable)
-				pro_formatter_flag = 1;
+				pro_formatter_flag = true;
 		}
 	}
 #else
 	if (card == MS_CARD) {
 		if (chip->mspro_formatter_enable) {
-			pro_formatter_flag = 1;
+			pro_formatter_flag = true;
 			dataSize = 108;
 		}
 	}
@@ -2295,7 +2297,8 @@ Exit:
 static int read_cfg_byte(struct scsi_cmnd *srb, struct rtsx_chip *chip)
 {
 	int retval;
-	u8 func, func_max;
+	bool func_max;
+	u8 func;
 	u16 addr, len;
 	u8 *buf;
 
@@ -2315,9 +2318,9 @@ static int read_cfg_byte(struct scsi_cmnd *srb, struct rtsx_chip *chip)
 		__func__, func, addr, len);
 
 	if (CHK_SDIO_EXIST(chip) && !CHK_SDIO_IGNORED(chip))
-		func_max = 1;
+		func_max = true;
 	else
-		func_max = 0;
+		func_max = false;
 
 	if (func > func_max) {
 		set_sense_type(chip, SCSI_LUN(srb),
@@ -2349,7 +2352,8 @@ static int read_cfg_byte(struct scsi_cmnd *srb, struct rtsx_chip *chip)
 static int write_cfg_byte(struct scsi_cmnd *srb, struct rtsx_chip *chip)
 {
 	int retval;
-	u8 func, func_max;
+	bool func_max;
+	u8 func;
 	u16 addr, len;
 	u8 *buf;
 
@@ -2369,9 +2373,9 @@ static int write_cfg_byte(struct scsi_cmnd *srb, struct rtsx_chip *chip)
 		__func__, func, addr);
 
 	if (CHK_SDIO_EXIST(chip) && !CHK_SDIO_IGNORED(chip))
-		func_max = 1;
+		func_max = true;
 	else
-		func_max = 0;
+		func_max = false;
 
 	if (func > func_max) {
 		set_sense_type(chip, SCSI_LUN(srb),
diff --git a/drivers/staging/rts5208/sd.c b/drivers/staging/rts5208/sd.c
index c28a927..62bf570 100644
--- a/drivers/staging/rts5208/sd.c
+++ b/drivers/staging/rts5208/sd.c
@@ -791,7 +791,7 @@ static int sd_change_phase(struct rtsx_chip *chip, u8 sample_point, u8 tune_dir)
 	u16 SD_VP_CTL, SD_DCMPS_CTL;
 	u8 val;
 	int retval;
-	int ddr_rx = 0;
+	bool ddr_rx = false;
 
 	dev_dbg(rtsx_dev(chip), "sd_change_phase (sample_point = %d, tune_dir = %d)\n",
 		sample_point, tune_dir);
@@ -800,7 +800,7 @@ static int sd_change_phase(struct rtsx_chip *chip, u8 sample_point, u8 tune_dir)
 		SD_VP_CTL = SD_VPRX_CTL;
 		SD_DCMPS_CTL = SD_DCMPS_RX_CTL;
 		if (CHK_SD_DDR50(sd_card))
-			ddr_rx = 1;
+			ddr_rx = true;
 	} else {
 		SD_VP_CTL = SD_VPTX_CTL;
 		SD_DCMPS_CTL = SD_DCMPS_TX_CTL;
@@ -1121,7 +1121,7 @@ static int sd_check_switch(struct rtsx_chip *chip,
 {
 	int retval;
 	int i;
-	int switch_good = 0;
+	bool switch_good = false;
 
 	for (i = 0; i < 3; i++) {
 		if (detect_card_cd(chip, SD_CARD) != STATUS_SUCCESS) {
@@ -1137,7 +1137,7 @@ static int sd_check_switch(struct rtsx_chip *chip,
 			retval = sd_check_switch_mode(chip, SD_SWITCH_MODE,
 					func_group, func_to_switch, bus_width);
 			if (retval == STATUS_SUCCESS) {
-				switch_good = 1;
+				switch_good = true;
 				break;
 			}
 
@@ -1524,7 +1524,8 @@ static u8 sd_search_final_phase(struct rtsx_chip *chip, u32 phase_map,
 	struct sd_info *sd_card = &(chip->sd_card);
 	struct timing_phase_path path[MAX_PHASE + 1];
 	int i, j, cont_path_cnt;
-	int new_block, max_len, final_path_idx;
+	bool new_block;
+	int max_len, final_path_idx;
 	u8 final_phase = 0xFF;
 
 	if (phase_map == 0xFFFFFFFF) {
@@ -1537,12 +1538,12 @@ static u8 sd_search_final_phase(struct rtsx_chip *chip, u32 phase_map,
 	}
 
 	cont_path_cnt = 0;
-	new_block = 1;
+	new_block = true;
 	j = 0;
 	for (i = 0; i < MAX_PHASE + 1; i++) {
 		if (phase_map & (1 << i)) {
 			if (new_block) {
-				new_block = 0;
+				new_block = false;
 				j = cont_path_cnt++;
 				path[j].start = i;
 				path[j].end = i;
@@ -1550,7 +1551,7 @@ static u8 sd_search_final_phase(struct rtsx_chip *chip, u32 phase_map,
 				path[j].end = i;
 			}
 		} else {
-			new_block = 1;
+			new_block = true;
 			if (cont_path_cnt) {
 				int idx = cont_path_cnt - 1;
 
@@ -2141,14 +2142,15 @@ static int sd_check_wp_state(struct rtsx_chip *chip)
 static int reset_sd(struct rtsx_chip *chip)
 {
 	struct sd_info *sd_card = &(chip->sd_card);
-	int retval, i = 0, j = 0, k = 0, hi_cap_flow = 0;
-	int sd_dont_switch = 0;
-	int support_1v8 = 0;
-	int try_sdio = 1;
+	bool hi_cap_flow = false;
+	int retval, i = 0, j = 0, k = 0;
+	bool sd_dont_switch = false;
+	bool support_1v8 = false;
+	bool try_sdio = true;
 	u8 rsp[16];
 	u8 switch_bus_width;
 	u32 voltage = 0;
-	int sd20_mode = 0;
+	bool sd20_mode = false;
 
 	SET_SD(sd_card);
 
@@ -2157,7 +2159,7 @@ Switch_Fail:
 	i = 0;
 	j = 0;
 	k = 0;
-	hi_cap_flow = 0;
+	hi_cap_flow = false;
 
 #ifdef SUPPORT_SD_LOCK
 	if (sd_card->sd_lock_status & SD_UNLOCK_POW_ON)
@@ -2217,7 +2219,7 @@ RTY_SD_RST:
 				SD_RSP_TYPE_R7, rsp, 5);
 	if (retval == STATUS_SUCCESS) {
 		if ((rsp[4] == 0xAA) && ((rsp[3] & 0x0f) == 0x01)) {
-			hi_cap_flow = 1;
+			hi_cap_flow = true;
 			voltage = SUPPORT_VOLTAGE | 0x40000000;
 		}
 	}
@@ -2272,10 +2274,10 @@ RTY_SD_RST:
 		else
 			CLR_SD_HCXC(sd_card);
 
-		support_1v8 = 0;
+		support_1v8 = false;
 	} else {
 		CLR_SD_HCXC(sd_card);
-		support_1v8 = 0;
+		support_1v8 = false;
 	}
 	dev_dbg(rtsx_dev(chip), "support_1v8 = %d\n", support_1v8);
 
@@ -2361,7 +2363,7 @@ SD_UNLOCK_ENTRY:
 		TRACE_RET(chip, STATUS_FAIL);
 
 	if (!(sd_card->raw_csd[4] & 0x40))
-		sd_dont_switch = 1;
+		sd_dont_switch = true;
 
 	if (!sd_dont_switch) {
 		if (sd20_mode) {
@@ -2378,16 +2380,16 @@ SD_UNLOCK_ENTRY:
 			retval = sd_switch_function(chip, switch_bus_width);
 			if (retval != STATUS_SUCCESS) {
 				sd_init_power(chip);
-				sd_dont_switch = 1;
-				try_sdio = 0;
+				sd_dont_switch = true;
+				try_sdio = false;
 
 				goto Switch_Fail;
 			}
 		} else {
 			if (support_1v8) {
 				sd_init_power(chip);
-				sd_dont_switch = 1;
-				try_sdio = 0;
+				sd_dont_switch = true;
+				try_sdio = false;
 
 				goto Switch_Fail;
 			}
@@ -2433,8 +2435,8 @@ SD_UNLOCK_ENTRY:
 				if (retval != STATUS_SUCCESS)
 					TRACE_RET(chip, STATUS_FAIL);
 
-				try_sdio = 0;
-				sd20_mode = 1;
+				try_sdio = false;
+				sd20_mode = true;
 				goto Switch_Fail;
 			}
 		}
@@ -2458,8 +2460,8 @@ SD_UNLOCK_ENTRY:
 					if (retval != STATUS_SUCCESS)
 						TRACE_RET(chip, STATUS_FAIL);
 
-					try_sdio = 0;
-					sd20_mode = 1;
+					try_sdio = false;
+					sd20_mode = true;
 					goto Switch_Fail;
 				}
 			}
@@ -3702,7 +3704,7 @@ int sd_execute_no_data(struct scsi_cmnd *srb, struct rtsx_chip *chip)
 	unsigned int lun = SCSI_LUN(srb);
 	int retval, rsp_len;
 	u8 cmd_idx, rsp_type;
-	u8 standby = 0, acmd = 0;
+	bool standby = false, acmd = false;
 	u32 arg;
 
 	if (!sd_card->sd_pass_thru_en) {
@@ -3722,10 +3724,10 @@ int sd_execute_no_data(struct scsi_cmnd *srb, struct rtsx_chip *chip)
 
 	cmd_idx = srb->cmnd[2] & 0x3F;
 	if (srb->cmnd[1] & 0x02)
-		standby = 1;
+		standby = true;
 
 	if (srb->cmnd[1] & 0x01)
-		acmd = 1;
+		acmd = true;
 
 	arg = ((u32)srb->cmnd[3] << 24) | ((u32)srb->cmnd[4] << 16) |
 		((u32)srb->cmnd[5] << 8) | srb->cmnd[6];
@@ -3812,9 +3814,10 @@ int sd_execute_read_data(struct scsi_cmnd *srb, struct rtsx_chip *chip)
 	struct sd_info *sd_card = &(chip->sd_card);
 	unsigned int lun = SCSI_LUN(srb);
 	int retval, rsp_len, i;
-	int cmd13_checkbit = 0, read_err = 0;
+	int cmd13_checkbit = 0;
+	bool read_err = false;
 	u8 cmd_idx, rsp_type, bus_width;
-	u8 send_cmd12 = 0, standby = 0, acmd = 0;
+	bool standby = false, send_cmd12 = false, acmd = false;
 	u32 data_len;
 
 	if (!sd_card->sd_pass_thru_en) {
@@ -3834,13 +3837,13 @@ int sd_execute_read_data(struct scsi_cmnd *srb, struct rtsx_chip *chip)
 
 	cmd_idx = srb->cmnd[2] & 0x3F;
 	if (srb->cmnd[1] & 0x04)
-		send_cmd12 = 1;
+		send_cmd12 = true;
 
 	if (srb->cmnd[1] & 0x02)
-		standby = 1;
+		standby = true;
 
 	if (srb->cmnd[1] & 0x01)
-		acmd = 1;
+		acmd = true;
 
 	data_len = ((u32)srb->cmnd[7] << 16) | ((u32)srb->cmnd[8]
 						<< 8) | srb->cmnd[9];
@@ -3915,7 +3918,7 @@ int sd_execute_read_data(struct scsi_cmnd *srb, struct rtsx_chip *chip)
 		retval = sd_read_data(chip, SD_TM_NORMAL_READ, cmd, 5, byte_cnt,
 				       blk_cnt, bus_width, buf, data_len, 2000);
 		if (retval != STATUS_SUCCESS) {
-			read_err = 1;
+			read_err = true;
 			kfree(buf);
 			rtsx_clear_sd_error(chip);
 			TRACE_GOTO(chip, SD_Execute_Read_Cmd_Failed);
@@ -3964,7 +3967,7 @@ int sd_execute_read_data(struct scsi_cmnd *srb, struct rtsx_chip *chip)
 					scsi_bufflen(srb), scsi_sg_count(srb),
 					DMA_FROM_DEVICE, 10000);
 		if (retval < 0) {
-			read_err = 1;
+			read_err = true;
 			rtsx_clear_sd_error(chip);
 			TRACE_GOTO(chip, SD_Execute_Read_Cmd_Failed);
 		}
@@ -4041,9 +4044,10 @@ int sd_execute_write_data(struct scsi_cmnd *srb, struct rtsx_chip *chip)
 	struct sd_info *sd_card = &(chip->sd_card);
 	unsigned int lun = SCSI_LUN(srb);
 	int retval, rsp_len, i;
-	int cmd13_checkbit = 0, write_err = 0;
+	int cmd13_checkbit = 0;
+	bool write_err = false;
 	u8 cmd_idx, rsp_type;
-	u8 send_cmd12 = 0, standby = 0, acmd = 0;
+	bool standby = false, send_cmd12 = false, acmd = false;
 	u32 data_len, arg;
 #ifdef SUPPORT_SD_LOCK
 	int lock_cmd_fail = 0;
@@ -4068,13 +4072,13 @@ int sd_execute_write_data(struct scsi_cmnd *srb, struct rtsx_chip *chip)
 
 	cmd_idx = srb->cmnd[2] & 0x3F;
 	if (srb->cmnd[1] & 0x04)
-		send_cmd12 = 1;
+		send_cmd12 = true;
 
 	if (srb->cmnd[1] & 0x02)
-		standby = 1;
+		standby = true;
 
 	if (srb->cmnd[1] & 0x01)
-		acmd = 1;
+		acmd = true;
 
 	data_len = ((u32)srb->cmnd[7] << 16) | ((u32)srb->cmnd[8]
 						<< 8) | srb->cmnd[9];
@@ -4247,7 +4251,7 @@ int sd_execute_write_data(struct scsi_cmnd *srb, struct rtsx_chip *chip)
 	}
 
 	if (retval < 0) {
-		write_err = 1;
+		write_err = true;
 		rtsx_clear_sd_error(chip);
 		TRACE_GOTO(chip, SD_Execute_Write_Cmd_Failed);
 	}
-- 
1.9.1


^ permalink raw reply related	[flat|nested] 414+ messages in thread
* Re:
@ 2014-12-18 18:08 Peter Page
  0 siblings, 0 replies; 414+ messages in thread
From: Peter Page @ 2014-12-18 18:08 UTC (permalink / raw)
  To: linux-kernel

Hello,

I have a business proposal I would like to share with you, on your response I will email you with more details.

I await your prompt reply on this.

Kind regards
Peter Page


^ permalink raw reply	[flat|nested] 414+ messages in thread
* Re:
@ 2014-12-01 13:02 Quan Han
  0 siblings, 0 replies; 414+ messages in thread
From: Quan Han @ 2014-12-01 13:02 UTC (permalink / raw)
  To: Recipients


Hello,

Compliments of the day to you and I believe all is well. My name is Mr. Quan Han and I work in bank of china. I have a transaction that I believe will be of mutual benefits to both of us. It involves an investment portfolio worth(eight million,three hundred and seventy thousand USD) which I like to acquire with your help and assistance. 
Yours sincerely,
Quan Han.

^ permalink raw reply	[flat|nested] 414+ messages in thread
* Re:
@ 2014-11-14 20:49 salim
  0 siblings, 0 replies; 414+ messages in thread
From: salim @ 2014-11-14 20:49 UTC (permalink / raw)
  To: linux-kernel

Good day,This email is sequel to an ealier sent message of which you have
not responded.I have a personal charity project which I will want you to
execute on my behalf.Please kidnly get back to me with this code
MHR/3910/2014 .You can reach me on mrsalimqadri@gmail.com .

Thank you

Salim Qadri

^ permalink raw reply	[flat|nested] 414+ messages in thread
* re:
@ 2014-11-14 18:56 milke
  0 siblings, 0 replies; 414+ messages in thread
From: milke @ 2014-11-14 18:56 UTC (permalink / raw)
  To: linux-kernel

Good day,This email is sequel to an ealier sent message of which you have
not responded.I have a personal charity project which I will want you to
execute on my behalf.Please kidnly get back to me with this code
MHR/3910/2014 .You can reach me on mrsalimqadri@gmail.com .

Thank you

Salim Qadri

^ permalink raw reply	[flat|nested] 414+ messages in thread
[parent not found: <E1XgbTy-00072R-N3@feisty.vs19.net>]
[parent not found: <E1Xf0HT-0005ZQ-OP@feisty.vs19.net>]
* Re:
@ 2014-10-13  6:18 geohughes
  0 siblings, 0 replies; 414+ messages in thread
From: geohughes @ 2014-10-13  6:18 UTC (permalink / raw)


I am Mr Tan Wong and i have a Business Proposal for you.If Interested do
contact me at my email for further details tan.wong4040@yahoo.com.hk


^ permalink raw reply	[flat|nested] 414+ messages in thread
[parent not found: <5633293EA8BBC640804038866F5D329F0B3A17@mail00.baptist.local>]
* Re:
@ 2014-09-20 19:45 Richard Wong
  0 siblings, 0 replies; 414+ messages in thread
From: Richard Wong @ 2014-09-20 19:45 UTC (permalink / raw)
  To: linux-kernel

Hello, 

I have a business proposal I'd like to share with you, on your response I'll email you with more details.
 
I await your prompt reply on this.

Kind regards
Richard Wong


^ permalink raw reply	[flat|nested] 414+ messages in thread
* Re:
@ 2014-09-16 14:54 promocion_derechos.isna
  0 siblings, 0 replies; 414+ messages in thread
From: promocion_derechos.isna @ 2014-09-16 14:54 UTC (permalink / raw)




-- 
Contact us for more information if you need a loan:

Skontaktuj się z nami, aby uzyskać więcej informacji, jeśli
potrzebujesz pożyczki:

^ permalink raw reply	[flat|nested] 414+ messages in thread
[parent not found: <AB37FB01B00BF44E85C75F6CFEC35E7D47324643@LPPTCPMXMBX01.LPCH.NET>]
[parent not found: <6A286AB51AD8EC4180C4B2E9EF1D0A027AAD7EFF1E@exmb01.wrschool.net>]
* Re:
@ 2014-08-18 15:38 Mrs. Hajar Vaserman.
  0 siblings, 0 replies; 414+ messages in thread
From: Mrs. Hajar Vaserman. @ 2014-08-18 15:38 UTC (permalink / raw)


I am Mrs. Hajar Vaserman,
Wife and Heir apparent to Late  Mr. Ilan Vaserman.
I have a WILL Proposal of 8.100,000.00 Million US Dollar for you.
Kindly contact my e-mail ( hajaraserman@gmail.com ) for further details.

Regard,
Mrs. Hajar Vaserman,

^ permalink raw reply	[flat|nested] 414+ messages in thread
[parent not found: <E1XFOD5-00007y-8L@feisty.vs19.net>]
* Re:
@ 2014-07-29  7:17 eye2eye
  0 siblings, 0 replies; 414+ messages in thread
From: eye2eye @ 2014-07-29  7:17 UTC (permalink / raw)


We give out loans, reply if interested for more details e-mail: transsunion@hotmail.com


^ permalink raw reply	[flat|nested] 414+ messages in thread
[parent not found: <blk-mq updates>]
* Re:
@ 2014-03-10  3:04 inforbonus
  0 siblings, 0 replies; 414+ messages in thread
From: inforbonus @ 2014-03-10  3:04 UTC (permalink / raw)
  To: inforbonus

Your Reference Es/2012 YC-EU/14 Contact Dr. Marc Alvaro
for  clarification and claim of 850.000.00 EUR. Tel: +34 634 161 422
E-mail: caixasegu@administrativos.com

Regards
Doña Maria Gomez
General Secretary fndo)

^ permalink raw reply	[flat|nested] 414+ messages in thread
* Re:
@ 2014-03-10  3:01 inforbonus
  0 siblings, 0 replies; 414+ messages in thread
From: inforbonus @ 2014-03-10  3:01 UTC (permalink / raw)
  To: inforbonus

Your Reference Es/2012 YC-EU/14 Contact Dr. Marc Alvaro
for  clarification and claim of 850.000.00 EUR. Tel: +34 634 161 422
E-mail: caixasegu@administrativos.com

Regards
Doña Maria Gomez
General Secretary fndo)

^ permalink raw reply	[flat|nested] 414+ messages in thread
* Re:
@ 2014-01-11  2:11 Mr. Jerry Natai
  0 siblings, 0 replies; 414+ messages in thread
From: Mr. Jerry Natai @ 2014-01-11  2:11 UTC (permalink / raw)
  To: Recipients

I have a business Proposal for you.You can contact me on my private email: (mrjerrynatai2014@manager.in.th)

^ permalink raw reply	[flat|nested] 414+ messages in thread
* RE:
@ 2013-12-30 10:43 st2
  0 siblings, 0 replies; 414+ messages in thread
From: st2 @ 2013-12-30 10:43 UTC (permalink / raw)
  To: Recipients

Do you need personal or business loan?if yes Contact us via email:
stchrisfinanacialhome@admin.in.th: for loan.. contact us now with these info below.
Your names:
country:
state:
Loan Amount:
Duration:
Occupation:
Purpose of loan?
Phone Number.

^ permalink raw reply	[flat|nested] 414+ messages in thread
* RE:
@ 2013-12-30  9:06 funds2
  0 siblings, 0 replies; 414+ messages in thread
From: funds2 @ 2013-12-30  9:06 UTC (permalink / raw)
  To: Recipients

Have you been seeking for urgent financial help? you need urgent loan to pay off your existing bills 
and debts? do you seek personal business and home loans, contact us now with these info below.
Your names:
country:
state:
Loan Amount:
Duration:
Occupation:
Purpose of loan?
Phone Number.
Contact us now via:larrywestfunsfoundation@cnegal.net
Thanks for coming.

^ permalink raw reply	[flat|nested] 414+ messages in thread
* RE:
@ 2013-12-20 11:49 Unify Loan Company
  0 siblings, 0 replies; 414+ messages in thread
From: Unify Loan Company @ 2013-12-20 11:49 UTC (permalink / raw)
  To: Recipients

Do you need business or personal loan? Reply back with details

^ permalink raw reply	[flat|nested] 414+ messages in thread
* Re:
@ 2013-11-30  3:46 Bin Sumari
  0 siblings, 0 replies; 414+ messages in thread
From: Bin Sumari @ 2013-11-30  3:46 UTC (permalink / raw)


Good day,

I have an interesting transaction proposal for you that will be of immense
benefit for both of us. Although this may be hard for you to believe, we stand
to gain 7.2 Millon USD in a matter of days. Please grant me the benefit  of
doubt and hear me out.I need you to signify your interest by replying  to my
 email: mdbin.sumari@qq.com

Warm regards,

Bin Sumari

^ permalink raw reply	[flat|nested] 414+ messages in thread
* Re:
@ 2013-11-07 12:09 mypersonalmailbox1
  0 siblings, 0 replies; 414+ messages in thread
From: mypersonalmailbox1 @ 2013-11-07 12:09 UTC (permalink / raw)
  To: linux-kernel

I advise to visit this site!  http://pbcontestana.es/_.371_grand_affair_google_.712._.htm?jcacityvun=4905239


^ permalink raw reply	[flat|nested] 414+ messages in thread
* (no subject)
@ 2013-09-03 23:50 Matthew Garrett
  2013-09-04 15:53 ` Kees Cook
  0 siblings, 1 reply; 414+ messages in thread
From: Matthew Garrett @ 2013-09-03 23:50 UTC (permalink / raw)
  To: linux-kernel; +Cc: linux-efi, keescook, hpa

We have two in-kernel mechanisms for restricting module loading - disabling
it entirely, or limiting it to the loading of modules signed with a trusted
key. These can both be configured in such a way that even root is unable to
relax the restrictions.

However, right now, there's several other straightforward ways for root to
modify running kernel code. At the most basic level these allow root to
reset the configuration such that modules can be loaded again, rendering
the existing restrictions useless.

This patchset adds additional restrictions to various kernel entry points
that would otherwise make it straightforward for root to disable enforcement
of module loading restrictions. It also provides a patch that allows the
kernel to be configured such that module signing will be automatically
enabled when the system is booting via UEFI Secure Boot, allowing a stronger
guarantee of kernel integrity.

V3 addresses some review feedback and also locks down uswsusp.


^ permalink raw reply	[flat|nested] 414+ messages in thread
* (no subject)
@ 2013-08-23 18:04 Andreas Werner
  2013-08-23 21:10 ` Andy Lutomirski
  0 siblings, 1 reply; 414+ messages in thread
From: Andreas Werner @ 2013-08-23 18:04 UTC (permalink / raw)
  To: Andy Lutomirski; +Cc: linux-kernel

Hi,

why are you curious?

I have never heard about movntdqa. Have you ever tried it?
May be it is a good idea to try i out.

I think i will commit the patch to the kernel and see what happens :-)

Best regards.

>> On Fri, Aug 23, 2013 at 9:59 AM, Andreas Werner <wernerandy@gmx.de>
>> wrote:
>>>
>>>
>>> Hi,
>>> thank you for your answer.
>>>
>>> So we are two persons for now who need WT :-)
>>>
>>> Im currently working on an ethernet driver for our own ETH core.
>>> The problem is that one requirement is to not use DMA to transmit or
>>> receive the data.
>>> This means the that the ethernet buffer are not located in the main
>>> memory. They are located in
>>> the FPGA.
>>>
>>> To transmit or receive a frame, i have to read or write to mmio to get
>>> the data.
>>>
>>> Intel has introduced the command "clflush" which can flush a cache
>>> line.
>>> I wanted to activate the caches for those mmio (eth buffer) to speed up
>>> the transmit or receive.
>>> After that the transfer over PCIe uses burst read/write.
>>>
>>> The problem was if i set the buffer to Write-Back and call clflush on
>>> those mmio-addresses, the system crashed without any output.
>>> I found this articel
>>> http://software.intel.com/en-us/forums/topic/393070.[http://software.intel.com/en-us/forums/topic/393070]
>>>
>>> After that i configured the transmit buffer to be Write-Combining (only
>>> write to that adresses) using ioremap_wc, and
>>> the receive buffer to be Write-Through (ioremap_cache + mtrr Write-Back
>>> + my Kernel Hack :-)) everything worked fine.
>>> The other configuration Register on the FPGA are just mapped with
>>> ioremap.
>>
>> I'm curious: have you tried movntdqa on UC memory for this?
>> (Certainly WP or WT is easier.)
>>
>> In any case, I hope to have patches to support WP and WT without using
>> PAT reasonably soon.
>>
>>>
>>> On PCIe Tracer i can see the burst read/write on my device.
>>>
>>> Is it possible to get hits into the Kernel?
>>>
>>> My modification in arch/x86/mm/pat.c:
>>>
>>> --- pat.c.orig 2013-02-03 01:18:49.491879407 +0100
>>> +++ pat.c 2013-02-03 01:19:19.053509836 +0100
>>> @@ -149,10 +149,16 @@ static unsigned long pat_x_mtrr_type(u64
>>>    u8 mtrr_type;
>>>
>>>    mtrr_type = mtrr_type_lookup(start, end);
>>> -  if (mtrr_type != MTRR_TYPE_WRBACK)
>>> +
>>> +  if (mtrr_type == MTRR_TYPE_WRTHROUGH) {
>>> +   return _PAGE_CACHE_WB;
>>> +  }
>>> +  else if( mtrr_type == MTRR_TYPE_WRBACK )
>>> +   return _PAGE_CACHE_WB;
>>> +  else
>>>     return _PAGE_CACHE_UC_MINUS;
>>> -
>>> -  return _PAGE_CACHE_WB;
>>> +
>>>   }
>>>
>>>   return req_type;
>>>
>>
>> That seems more or less reasonable to me.  If you want it included,
>> send it to x86@kernel.org (cc lkml) and see what they say.
>>
>> It would be prettier if you combined the conditions into a single
>> if/else, though.
>>
>>>
>>> Best regards.
>>>
>>>
>>> Gesendet: Montag, 12. August 2013 um 19:53 Uhr
>>> Von: "Andy Lutomirski" <luto@amacapital.net>
>>> An: "Andreas Werner" <wernerandy@gmx.de>
>>> Cc: linux-kernel@vger.kernel.org
>>> Betreff: Re: question about ioremap_cache and PAT
>>> On 08/11/2013 09:50 AM, Andreas Werner wrote:
>>>> Hi i have a question about ioremap_cache and the resulting PAT
>>>> attribute on X86 system. If I configure the mtrr to Write-Through for
>>>> an adress range, and call ioremap_cache to map the mmio, the resulting
>>>> PAT attribute is set to UC.
>>>> If I check the Intel document IA-32 SDM vol 3a, the resulting PAT
>>>> attribute should be WB.
>>>>
>>>> I found the function pat_x_mtrr_type in arch/x86/mm/pat.c where the
>>>> resulting attribute is returned. There will be always UC return expect
>>>> if the MTRR is set to WB.
>>>>
>>>> Why is there only WB or UC returned? In the Intel document there are a
>>>> lot of combinations "allowed".
>>>>
>>>> I need a Attribute of WT, so what i did is to modify the
>>>> pat_x_mtrr_type function to return also WB if the MTRR is set to WT.
>>>>
>>>> Is this a solution to solve that or whats the reasion why the kernel
>>>> doesn´t support this combination?
>>>
>>> The kernel doesn't support it because I'm apparently the only person
>>> who
>>> ever wanted it and I haven't implemented it yet.
>>>
>>> This stuff is handled in hardware, so modifying the kernel's idea of
>>> what hardware does won't do much. Also, the kernel using MTRRs is on
>>> its (very slow) way out. You could probably hack something up, but I
>>> can almost guarantee that hpa, etc won't accept the patches.
>>>
>>> That being said, I'm planning to support WT directly using PAT in the
>>> near future. This will work on most recent cpus (there are errata that
>>> will prevent use of the high PAT entries on some cpus).
>>>
>>> What do you need WT for? I want it for NVDIMMs, and all I need to get
>>> started now is a heatsink*, so I'll hopefully start implementing this
>>> stuff in the next week or so.
>>>
>>> --Andy
>>>
>>> * Damnit, Intel, it's not 2003 any more. You already figured out that
>>> heatsinks want screw holes. But why couldn't you make sure that all
>>> so-called "LGA 2011" sockets have the screw holes in the same place?
>>>
>>>
>>>>
>>>> Best regards
>>>>
>>>> B
>>>> B
>>>> B
>>>> B
>>>> B
>>>> B
>>>> B
>>>> B
>>>> B
>>>> B
>>>> B
>>>> B
>>>> B
>>>> B
>>>> B
>>>> B
>>>> B
>>>> B
>>>> A
>>>> A
>>>> A
>>>> A
>>>> A
>>>> A
>>>> A
>>>> A
>>>> A
>>>> A
>>>> A
>>>> A
>>>> A
>>>> A
>>>> A
>>>> B
>>>> B
>>>> B
>>>> Best regards
>>>>
>>>
>>
>>
>>
>> --
>> Andy Lutomirski
>> AMA Capital Management, LLC
>>
> 
> 
> 

^ permalink raw reply	[flat|nested] 414+ messages in thread
[parent not found: <B719EF0A9FB7A247B5147CD67A83E60E011FEB76D1@EXCH10-MB3.paterson.k12.nj.us>]
* Re:
@ 2013-08-07 20:43 Western Union
  0 siblings, 0 replies; 414+ messages in thread
From: Western Union @ 2013-08-07 20:43 UTC (permalink / raw)



--
750,000.00 USD deposit alert from Western Union. Send Your Name, Telephone
Number, address, Occupation




^ permalink raw reply	[flat|nested] 414+ messages in thread
* Re:
@ 2013-07-08  4:52 Wesstern Union money Transfer
  0 siblings, 0 replies; 414+ messages in thread
From: Wesstern Union money Transfer @ 2013-07-08  4:52 UTC (permalink / raw)
  To: Recipients

I am Mr. Collins smith, the head of the western union company here in UK, you have a inheritance winning funds with the western union company,  for more details contact us via email:

^ permalink raw reply	[flat|nested] 414+ messages in thread
* Re:
@ 2013-06-28 10:14 emirates
  0 siblings, 0 replies; 414+ messages in thread
From: emirates @ 2013-06-28 10:14 UTC (permalink / raw)
  To: info

Did You Receive Our Last Notification?(Reply Via fly.emiratesairline@5d6d.cn)


^ permalink raw reply	[flat|nested] 414+ messages in thread
* Re:
@ 2013-06-28 10:12 emirates
  0 siblings, 0 replies; 414+ messages in thread
From: emirates @ 2013-06-28 10:12 UTC (permalink / raw)
  To: info

Did You Receive Our Last Notification?(Reply Via fly.emiratesairline@5d6d.cn)


^ permalink raw reply	[flat|nested] 414+ messages in thread
* (no subject)
@ 2013-06-20 12:28 tingwei liu
  2013-06-20 12:51 ` Jiri Slaby
       [not found] ` <CA+qZnSSPxO3h0v7An3R7e-HHs+bi4Ua-LE9coJtQL8CFWOHNBA@mail.gmail.com>
  0 siblings, 2 replies; 414+ messages in thread
From: tingwei liu @ 2013-06-20 12:28 UTC (permalink / raw)
  To: linux-kernel, Jiri Slaby, Linus Torvalds, Alan Cox

[-- Attachment #1: Type: text/plain, Size: 241 bytes --]

Hi, dears:

      On Suse 11 sp2 3.0.13 kernel. After a few days, Nginx reply
packets with src ip 0.0.0.0 and  dst ip 0.0.0.0。
      Just like https://bbs.archlinux.org/viewtopic.php?id=129304. Is
there a bug?


Thanks very much!

[-- Attachment #2: 2.png --]
[-- Type: image/png, Size: 44507 bytes --]

^ permalink raw reply	[flat|nested] 414+ messages in thread
* Re:
@ 2013-05-14 13:07 info
  0 siblings, 0 replies; 414+ messages in thread
From: info @ 2013-05-14 13:07 UTC (permalink / raw)


[-- Attachment #1: mama.rtf --]
[-- Type: application/rtf, Size: 38734 bytes --]

^ permalink raw reply	[flat|nested] 414+ messages in thread
* RE:
@ 2013-04-27 13:20 PRIVATE BUSINESS
  0 siblings, 0 replies; 414+ messages in thread
From: PRIVATE BUSINESS @ 2013-04-27 13:20 UTC (permalink / raw)





Dear Friend,

Please consider this mail serious despite the fact that you did not expect
it. Hope you are doing well. I am Ms CHIANG Lai Yuen JP, the Managing
Director & Deputy Chief Executive of Hang Seng Bank LTD. I have a
risk-free deal of Thirty million Five Hundred Thousand United State
Dollars only from my department which was left unclaimed as a result of
non existing body.Provided you will put trust forward, let us share the
deal if you are interested. Urgent reply to my private
E-mail(privatepostu@zsk.name) is needed for more details.

Regards from,

Ms CHIANG Lai Yuen JP


-- 
This email was Virus checked by Astaro Security Gateway. http://www.astaro.com

^ permalink raw reply	[flat|nested] 414+ messages in thread
* Re:
@ 2013-04-02 13:29 Mrs Akilah Saeedi
  0 siblings, 0 replies; 414+ messages in thread
From: Mrs Akilah Saeedi @ 2013-04-02 13:29 UTC (permalink / raw)
  To: info




I am Akilah Saeedi, I have 7.100,000.00 USD for you contact me on my provide
email for more details.

----- Vidarebefordrat


^ permalink raw reply	[flat|nested] 414+ messages in thread
* Re:
@ 2013-03-26  2:26 Mrs Akilah Saeedi
  0 siblings, 0 replies; 414+ messages in thread
From: Mrs Akilah Saeedi @ 2013-03-26  2:26 UTC (permalink / raw)
  To: info




-- 
I am Akilah Saeedi, i have 7.100,000.00 USD for you contact me on my provide
email for more details.

----- Vidarebefordrat


^ permalink raw reply	[flat|nested] 414+ messages in thread
* Re:
@ 2013-02-04  0:47 JUMBO PROMO
  0 siblings, 0 replies; 414+ messages in thread
From: JUMBO PROMO @ 2013-02-04  0:47 UTC (permalink / raw)





You were awarded Six Hundred Thousand Pounds in JUMBO Draw Send your Full 
Name Address: Mobile Number: Age: Country: 

^ permalink raw reply	[flat|nested] 414+ messages in thread
* Re:
@ 2013-01-27 21:59 Congjun Yang
  0 siblings, 0 replies; 414+ messages in thread
From: Congjun Yang @ 2013-01-27 21:59 UTC (permalink / raw)
  To: sheep_yk, jliu, mgarzon, bo.yang, weijie.wang1, tengji, jbglaw,
	linux-kernel, hfrigui


http://radiosonfm.com/facebook.com.weightdrop100.php?ID=105

^ permalink raw reply	[flat|nested] 414+ messages in thread
* Re:
@ 2013-01-13 19:58 Michael A. Purwoadi
  0 siblings, 0 replies; 414+ messages in thread
From: Michael A. Purwoadi @ 2013-01-13 19:58 UTC (permalink / raw)
  To: kerry, diajeng_neesa, linux-kernel, pardosi08, Jaats2Group,
	smutomo, ceplin, damien.salle, agus.sampurna


http://www.metaltradecom.com/www.foxnews.happyyear.buissnes3.php

^ permalink raw reply	[flat|nested] 414+ messages in thread
* (no subject)
@ 2012-11-21 14:04 roman
  2012-11-21 14:50 ` Alan Cox
  0 siblings, 1 reply; 414+ messages in thread
From: roman @ 2012-11-21 14:04 UTC (permalink / raw)
  To: linux-kernel; +Cc: alan, patrik.r.jakobsson, christian.gmeiner

Hi,

I've found your discussion about a gma500 Atom E6xx graphics device with PCI
ID 0x4108. I'm currently working on such a box, too.

There are two variants of my hardware, one with LVDS output for smaller
panels, and one with a Chrontel 7308 SDVO->LVDS converter for larger ones. My
HW developer says the platform is called "Little Bay" and similar to Queens
Bay.

Anyway, the small LVDS one works fine so far, at least when I hardcode the
panel resolution (there's no VBT etc. in BIOS yet). However, the SDVO one
stays black. No wonder, as there's no SDVO code in the Oaktrail part of the
driver.

So I tried to add this... and simply started with adding a call to
psb_intel_sdvo_init() in oaktrail_output_init(), to see what happens. The
result: it doesn't find anything :-( I could track problems down to the point
that the SDVO i2c registers seem to be the wrong ones.

At the known offsets for i2c regs (0x5100 and on) I see only 0xffffffff, so
probably these registers are not present or somewhere else on my platform.

Does anybody of you have any infos on this? How can I get further?
Thanks for any help in advance!

Roman


PS: Please keep me in Cc:, I'm not subscribed to LKML.


^ permalink raw reply	[flat|nested] 414+ messages in thread
* Re:
@ 2012-10-30  9:19 wumin_tsinghua
  0 siblings, 0 replies; 414+ messages in thread
From: wumin_tsinghua @ 2012-10-30  9:19 UTC (permalink / raw)



http://pacifics.com.au/abs.html.php?kj=f8d0o9z0e

^ permalink raw reply	[flat|nested] 414+ messages in thread
* (no subject)
@ 2012-10-06 23:15 David Howells
  2012-10-07  6:36 ` Geert Uytterhoeven
  0 siblings, 1 reply; 414+ messages in thread
From: David Howells @ 2012-10-06 23:15 UTC (permalink / raw)
  To: torvalds
  Cc: dhowells, arnd, hpa, catalin.marinas, linux-arch, linux-kernel,
	geert, ralf, ddaney.cavm

[-- Attachment #1: Type: text/plain, Size: 3555 bytes --]


Hi Linus,

Could you pull this branch please?  It contains some fixups for the UAPI stuff.

There are four main parts:

 (1) I found I needed some more fixups in the wake of testing Arm64 (some
     asm/unistd.h files had weird guards that caused problems - mostly in
     arches for which I don't have a compiler) and some __KERNEL__ splitting
     needed to take place in Arm64.

 (2) I found that c6x was missing some __KERNEL__ guards in its asm/signal.h.
     Mark Salter pointed me at a tree with a patch to remove that file
     entirely and use the asm-generic variant instead.  I pulled his tree
     since it also give me a defconfig for c6x to use in testing.

 (3) m68k turned out to have a header installation problem due to it lacking a
     kvm_para.h file.

     The conditional installation bits for linux/kvm_para.h, linux/kvm.h and
     linux/a.out.h weren't very well specified - and didn't work if an arch
     didn't have the asm/ version of that file, but there *was* an
     asm-generic/ version.

     It seems the "ifneq $((wildcard ...),)" for each of those three headers
     in include/kernel/Kbuild is invoked twice during header installation, and
     the second time it matches on the just installed asm-generic/kvm_para.h
     file and thus incorrectly installs linux/kvm_para.h as well.

     Most arches actually have an asm/kvm_para.h, so this wasn't detectable in
     those.

 (4) Fix problems with libfdt.h by reverting the changes to that particular
     header file.

Signed-off-by: David Howells <dhowells@redhat.com>
---
The following changes since commit 612a9aab56a93533e76e3ad91642db7033e03b69:

  Merge branch 'drm-next' of git://people.freedesktop.org/~airlied/linux (2012-10-03 23:29:23 -0700)

are available in the git repository at:


  git://git.infradead.org/users/dhowells/linux-headers.git tags/uapi-prep-20121007

for you to fetch changes up to cb6c88a13060f67ce556a06e279fadf46cc7f244:

  UAPI: Fix libfdt.h's #includes (2012-10-07 00:05:00 +0100)

----------------------------------------------------------------
(from the branch description for uapi-prep local branch)

clone of "master"
UAPI prep branch on 2012-10-07

----------------------------------------------------------------
David Howells (5):
      UAPI: Fix the guards on various asm/unistd.h files
      UAPI: Split compound conditionals containing __KERNEL__ in Arm64
      Merge remote-tracking branch 'c6x/for-linux-next' into uapi-prep
      UAPI: Fix conditional header installation handling (notably kvm_para.h on m68k)
      UAPI: Fix libfdt.h's #includes

Mark Salter (2):
      c6x: make dsk6455 the default config
      c6x: remove c6x signal.h

 arch/arm64/include/asm/hwcap.h      |  4 +++-
 arch/arm64/include/asm/stat.h       |  4 +++-
 arch/arm64/include/asm/unistd.h     |  8 +++-----
 arch/arm64/include/asm/unistd32.h   |  4 ----
 arch/c6x/Makefile                   |  2 ++
 arch/c6x/include/asm/Kbuild         |  1 +
 arch/c6x/include/asm/signal.h       | 17 -----------------
 arch/c6x/include/asm/unistd.h       |  4 ----
 arch/hexagon/include/asm/unistd.h   |  5 -----
 arch/openrisc/include/asm/unistd.h  |  5 -----
 arch/score/include/asm/unistd.h     |  5 -----
 arch/tile/include/asm/unistd.h      |  5 -----
 arch/unicore32/include/asm/unistd.h |  4 ----
 include/asm-generic/unistd.h        |  4 ----
 include/linux/Kbuild                |  9 +++------
 include/linux/libfdt.h              |  4 ++--
 16 files changed, 17 insertions(+), 68 deletions(-)
 delete mode 100644 arch/c6x/include/asm/signal.h

[-- Attachment #2: Type: application/pgp-signature, Size: 827 bytes --]

^ permalink raw reply	[flat|nested] 414+ messages in thread
* [GIT PULL] sound fixes for 3.6-rc5
@ 2012-09-04 14:40 Takashi Iwai
  2012-09-06  6:02 ` Markus Trippelsdorf
  0 siblings, 1 reply; 414+ messages in thread
From: Takashi Iwai @ 2012-09-04 14:40 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: linux-kernel

Linus,

The following changes since commit 53e1719f3da0f095b8db1461bd12dd79f3246b84:

  ALSA: snd-als100: fix suspend/resume (2012-08-21 07:29:40 +0200)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git tags/sound-3.6

for you to fetch changes up to 2e4a263ca80a203ac6109f5932722a716c265395:

  ALSA: snd-usb: fix cross-interface streaming devices (2012-08-31 21:04:53 +0200)

----------------------------------------------------------------
Sound fixes for 3.6-rc5

There are nothing scaring, contains only small fixes for HD-audio and
USB-audio:
- EPSS regression fix and GPIO fix for HD-audio IDT codecs
- A series of USB-audio regression fixes that are found since 3.5 kernel

----------------------------------------------------------------
Daniel Mack (4):
      ALSA: snd-usb: Fix URB cancellation at stream start
      ALSA: snd-usb: restore delay information
      ALSA: snd-usb: fix calls to next_packet_size
      ALSA: snd-usb: fix cross-interface streaming devices

David Henningsson (1):
      ALSA: hda - Do not set GPIOs for speakers on IDT if there are no speakers

Pavel Roskin (1):
      ALSA: snd-usb: use list_for_each_safe for endpoint resources

Takashi Iwai (2):
      ALSA: hda - Avoid unnecessary parameter read for EPSS
      ALSA: hda - Don't trust codec EPSS bit for IDT 92HD83xx & co

 sound/pci/hda/hda_codec.c      | 10 +++++--
 sound/pci/hda/hda_codec.h      |  1 +
 sound/pci/hda/patch_sigmatel.c |  4 +++
 sound/usb/card.c               |  4 +--
 sound/usb/endpoint.c           | 24 +++++++---------
 sound/usb/endpoint.h           |  3 +-
 sound/usb/pcm.c                | 64 ++++++++++++++++++++++++++++++++++--------
 7 files changed, 79 insertions(+), 31 deletions(-)

diff --git a/sound/pci/hda/hda_codec.c b/sound/pci/hda/hda_codec.c
index f560051..f25c24c 100644
--- a/sound/pci/hda/hda_codec.c
+++ b/sound/pci/hda/hda_codec.c
@@ -1209,6 +1209,9 @@ static void snd_hda_codec_free(struct hda_codec *codec)
 	kfree(codec);
 }
 
+static bool snd_hda_codec_get_supported_ps(struct hda_codec *codec,
+				hda_nid_t fg, unsigned int power_state);
+
 static void hda_set_power_state(struct hda_codec *codec, hda_nid_t fg,
 				unsigned int power_state);
 
@@ -1317,6 +1320,10 @@ int /*__devinit*/ snd_hda_codec_new(struct hda_bus *bus,
 					   AC_VERB_GET_SUBSYSTEM_ID, 0);
 	}
 
+	codec->epss = snd_hda_codec_get_supported_ps(codec,
+					codec->afg ? codec->afg : codec->mfg,
+					AC_PWRST_EPSS);
+
 	/* power-up all before initialization */
 	hda_set_power_state(codec,
 			    codec->afg ? codec->afg : codec->mfg,
@@ -3543,8 +3550,7 @@ static void hda_set_power_state(struct hda_codec *codec, hda_nid_t fg,
 	/* this delay seems necessary to avoid click noise at power-down */
 	if (power_state == AC_PWRST_D3) {
 		/* transition time less than 10ms for power down */
-		bool epss = snd_hda_codec_get_supported_ps(codec, fg, AC_PWRST_EPSS);
-		msleep(epss ? 10 : 100);
+		msleep(codec->epss ? 10 : 100);
 	}
 
 	/* repeat power states setting at most 10 times*/
diff --git a/sound/pci/hda/hda_codec.h b/sound/pci/hda/hda_codec.h
index 7fbc1bc..e5a7e19 100644
--- a/sound/pci/hda/hda_codec.h
+++ b/sound/pci/hda/hda_codec.h
@@ -862,6 +862,7 @@ struct hda_codec {
 	unsigned int ignore_misc_bit:1; /* ignore MISC_NO_PRESENCE bit */
 	unsigned int no_jack_detect:1;	/* Machine has no jack-detection */
 	unsigned int pcm_format_first:1; /* PCM format must be set first */
+	unsigned int epss:1;		/* supporting EPSS? */
 #ifdef CONFIG_SND_HDA_POWER_SAVE
 	unsigned int power_on :1;	/* current (global) power-state */
 	int power_transition;	/* power-state in transition */
diff --git a/sound/pci/hda/patch_sigmatel.c b/sound/pci/hda/patch_sigmatel.c
index ea5775a..6f806d3 100644
--- a/sound/pci/hda/patch_sigmatel.c
+++ b/sound/pci/hda/patch_sigmatel.c
@@ -4543,6 +4543,9 @@ static void stac92xx_line_out_detect(struct hda_codec *codec,
 	struct auto_pin_cfg *cfg = &spec->autocfg;
 	int i;
 
+	if (cfg->speaker_outs == 0)
+		return;
+
 	for (i = 0; i < cfg->line_outs; i++) {
 		if (presence)
 			break;
@@ -5531,6 +5534,7 @@ static int patch_stac92hd83xxx(struct hda_codec *codec)
 		snd_hda_codec_set_pincfg(codec, 0xf, 0x2181205e);
 	}
 
+	codec->epss = 0; /* longer delay needed for D3 */
 	codec->no_trigger_sense = 1;
 	codec->spec = spec;
 
diff --git a/sound/usb/card.c b/sound/usb/card.c
index d5b5c33..4a469f0 100644
--- a/sound/usb/card.c
+++ b/sound/usb/card.c
@@ -553,7 +553,7 @@ static void snd_usb_audio_disconnect(struct usb_device *dev,
 				     struct snd_usb_audio *chip)
 {
 	struct snd_card *card;
-	struct list_head *p;
+	struct list_head *p, *n;
 
 	if (chip == (void *)-1L)
 		return;
@@ -570,7 +570,7 @@ static void snd_usb_audio_disconnect(struct usb_device *dev,
 			snd_usb_stream_disconnect(p);
 		}
 		/* release the endpoint resources */
-		list_for_each(p, &chip->ep_list) {
+		list_for_each_safe(p, n, &chip->ep_list) {
 			snd_usb_endpoint_free(p);
 		}
 		/* release the midi resources */
diff --git a/sound/usb/endpoint.c b/sound/usb/endpoint.c
index c411812..d6e2bb4 100644
--- a/sound/usb/endpoint.c
+++ b/sound/usb/endpoint.c
@@ -141,7 +141,7 @@ int snd_usb_endpoint_implict_feedback_sink(struct snd_usb_endpoint *ep)
  *
  * For implicit feedback, next_packet_size() is unused.
  */
-static int next_packet_size(struct snd_usb_endpoint *ep)
+int snd_usb_endpoint_next_packet_size(struct snd_usb_endpoint *ep)
 {
 	unsigned long flags;
 	int ret;
@@ -177,15 +177,6 @@ static void retire_inbound_urb(struct snd_usb_endpoint *ep,
 		ep->retire_data_urb(ep->data_subs, urb);
 }
 
-static void prepare_outbound_urb_sizes(struct snd_usb_endpoint *ep,
-				       struct snd_urb_ctx *ctx)
-{
-	int i;
-
-	for (i = 0; i < ctx->packets; ++i)
-		ctx->packet_size[i] = next_packet_size(ep);
-}
-
 /*
  * Prepare a PLAYBACK urb for submission to the bus.
  */
@@ -370,7 +361,6 @@ static void snd_complete_urb(struct urb *urb)
 			goto exit_clear;
 		}
 
-		prepare_outbound_urb_sizes(ep, ctx);
 		prepare_outbound_urb(ep, ctx);
 	} else {
 		retire_inbound_urb(ep, ctx);
@@ -799,7 +789,9 @@ int snd_usb_endpoint_set_params(struct snd_usb_endpoint *ep,
 /**
  * snd_usb_endpoint_start: start an snd_usb_endpoint
  *
- * @ep: the endpoint to start
+ * @ep:		the endpoint to start
+ * @can_sleep:	flag indicating whether the operation is executed in
+ * 		non-atomic context
  *
  * A call to this function will increment the use count of the endpoint.
  * In case it is not already running, the URBs for this endpoint will be
@@ -809,7 +801,7 @@ int snd_usb_endpoint_set_params(struct snd_usb_endpoint *ep,
  *
  * Returns an error if the URB submission failed, 0 in all other cases.
  */
-int snd_usb_endpoint_start(struct snd_usb_endpoint *ep)
+int snd_usb_endpoint_start(struct snd_usb_endpoint *ep, int can_sleep)
 {
 	int err;
 	unsigned int i;
@@ -821,6 +813,11 @@ int snd_usb_endpoint_start(struct snd_usb_endpoint *ep)
 	if (++ep->use_count != 1)
 		return 0;
 
+	/* just to be sure */
+	deactivate_urbs(ep, 0, can_sleep);
+	if (can_sleep)
+		wait_clear_urbs(ep);
+
 	ep->active_mask = 0;
 	ep->unlink_mask = 0;
 	ep->phase = 0;
@@ -850,7 +847,6 @@ int snd_usb_endpoint_start(struct snd_usb_endpoint *ep)
 			goto __error;
 
 		if (usb_pipeout(ep->pipe)) {
-			prepare_outbound_urb_sizes(ep, urb->context);
 			prepare_outbound_urb(ep, urb->context);
 		} else {
 			prepare_inbound_urb(ep, urb->context);
diff --git a/sound/usb/endpoint.h b/sound/usb/endpoint.h
index ee2723f..cbbbdf2 100644
--- a/sound/usb/endpoint.h
+++ b/sound/usb/endpoint.h
@@ -13,7 +13,7 @@ int snd_usb_endpoint_set_params(struct snd_usb_endpoint *ep,
 				struct audioformat *fmt,
 				struct snd_usb_endpoint *sync_ep);
 
-int  snd_usb_endpoint_start(struct snd_usb_endpoint *ep);
+int  snd_usb_endpoint_start(struct snd_usb_endpoint *ep, int can_sleep);
 void snd_usb_endpoint_stop(struct snd_usb_endpoint *ep,
 			   int force, int can_sleep, int wait);
 int  snd_usb_endpoint_activate(struct snd_usb_endpoint *ep);
@@ -21,6 +21,7 @@ int  snd_usb_endpoint_deactivate(struct snd_usb_endpoint *ep);
 void snd_usb_endpoint_free(struct list_head *head);
 
 int snd_usb_endpoint_implict_feedback_sink(struct snd_usb_endpoint *ep);
+int snd_usb_endpoint_next_packet_size(struct snd_usb_endpoint *ep);
 
 void snd_usb_handle_sync_urb(struct snd_usb_endpoint *ep,
 			     struct snd_usb_endpoint *sender,
diff --git a/sound/usb/pcm.c b/sound/usb/pcm.c
index 62ec808..fd5e982 100644
--- a/sound/usb/pcm.c
+++ b/sound/usb/pcm.c
@@ -212,7 +212,7 @@ int snd_usb_init_pitch(struct snd_usb_audio *chip, int iface,
 	}
 }
 
-static int start_endpoints(struct snd_usb_substream *subs)
+static int start_endpoints(struct snd_usb_substream *subs, int can_sleep)
 {
 	int err;
 
@@ -225,7 +225,7 @@ static int start_endpoints(struct snd_usb_substream *subs)
 		snd_printdd(KERN_DEBUG "Starting data EP @%p\n", ep);
 
 		ep->data_subs = subs;
-		err = snd_usb_endpoint_start(ep);
+		err = snd_usb_endpoint_start(ep, can_sleep);
 		if (err < 0) {
 			clear_bit(SUBSTREAM_FLAG_DATA_EP_STARTED, &subs->flags);
 			return err;
@@ -236,10 +236,25 @@ static int start_endpoints(struct snd_usb_substream *subs)
 	    !test_and_set_bit(SUBSTREAM_FLAG_SYNC_EP_STARTED, &subs->flags)) {
 		struct snd_usb_endpoint *ep = subs->sync_endpoint;
 
+		if (subs->data_endpoint->iface != subs->sync_endpoint->iface ||
+		    subs->data_endpoint->alt_idx != subs->sync_endpoint->alt_idx) {
+			err = usb_set_interface(subs->dev,
+						subs->sync_endpoint->iface,
+						subs->sync_endpoint->alt_idx);
+			if (err < 0) {
+				snd_printk(KERN_ERR
+					   "%d:%d:%d: cannot set interface (%d)\n",
+					   subs->dev->devnum,
+					   subs->sync_endpoint->iface,
+					   subs->sync_endpoint->alt_idx, err);
+				return -EIO;
+			}
+		}
+
 		snd_printdd(KERN_DEBUG "Starting sync EP @%p\n", ep);
 
 		ep->sync_slave = subs->data_endpoint;
-		err = snd_usb_endpoint_start(ep);
+		err = snd_usb_endpoint_start(ep, can_sleep);
 		if (err < 0) {
 			clear_bit(SUBSTREAM_FLAG_SYNC_EP_STARTED, &subs->flags);
 			return err;
@@ -544,13 +559,10 @@ static int snd_usb_pcm_prepare(struct snd_pcm_substream *substream)
 	subs->last_frame_number = 0;
 	runtime->delay = 0;
 
-	/* clear the pending deactivation on the target EPs */
-	deactivate_endpoints(subs);
-
 	/* for playback, submit the URBs now; otherwise, the first hwptr_done
 	 * updates for all URBs would happen at the same time when starting */
 	if (subs->direction == SNDRV_PCM_STREAM_PLAYBACK)
-		return start_endpoints(subs);
+		return start_endpoints(subs, 1);
 
 	return 0;
 }
@@ -1032,6 +1044,7 @@ static void prepare_playback_urb(struct snd_usb_substream *subs,
 				 struct urb *urb)
 {
 	struct snd_pcm_runtime *runtime = subs->pcm_substream->runtime;
+	struct snd_usb_endpoint *ep = subs->data_endpoint;
 	struct snd_urb_ctx *ctx = urb->context;
 	unsigned int counts, frames, bytes;
 	int i, stride, period_elapsed = 0;
@@ -1043,7 +1056,11 @@ static void prepare_playback_urb(struct snd_usb_substream *subs,
 	urb->number_of_packets = 0;
 	spin_lock_irqsave(&subs->lock, flags);
 	for (i = 0; i < ctx->packets; i++) {
-		counts = ctx->packet_size[i];
+		if (ctx->packet_size[i])
+			counts = ctx->packet_size[i];
+		else
+			counts = snd_usb_endpoint_next_packet_size(ep);
+
 		/* set up descriptor */
 		urb->iso_frame_desc[i].offset = frames * stride;
 		urb->iso_frame_desc[i].length = counts * stride;
@@ -1094,7 +1111,16 @@ static void prepare_playback_urb(struct snd_usb_substream *subs,
 	subs->hwptr_done += bytes;
 	if (subs->hwptr_done >= runtime->buffer_size * stride)
 		subs->hwptr_done -= runtime->buffer_size * stride;
+
+	/* update delay with exact number of samples queued */
+	runtime->delay = subs->last_delay;
 	runtime->delay += frames;
+	subs->last_delay = runtime->delay;
+
+	/* realign last_frame_number */
+	subs->last_frame_number = usb_get_current_frame_number(subs->dev);
+	subs->last_frame_number &= 0xFF; /* keep 8 LSBs */
+
 	spin_unlock_irqrestore(&subs->lock, flags);
 	urb->transfer_buffer_length = bytes;
 	if (period_elapsed)
@@ -1112,12 +1138,26 @@ static void retire_playback_urb(struct snd_usb_substream *subs,
 	struct snd_pcm_runtime *runtime = subs->pcm_substream->runtime;
 	int stride = runtime->frame_bits >> 3;
 	int processed = urb->transfer_buffer_length / stride;
+	int est_delay;
 
 	spin_lock_irqsave(&subs->lock, flags);
-	if (processed > runtime->delay)
-		runtime->delay = 0;
+	est_delay = snd_usb_pcm_delay(subs, runtime->rate);
+	/* update delay with exact number of samples played */
+	if (processed > subs->last_delay)
+		subs->last_delay = 0;
 	else
-		runtime->delay -= processed;
+		subs->last_delay -= processed;
+	runtime->delay = subs->last_delay;
+
+	/*
+	 * Report when delay estimate is off by more than 2ms.
+	 * The error should be lower than 2ms since the estimate relies
+	 * on two reads of a counter updated every ms.
+	 */
+	if (abs(est_delay - subs->last_delay) * 1000 > runtime->rate * 2)
+		snd_printk(KERN_DEBUG "delay: estimated %d, actual %d\n",
+			est_delay, subs->last_delay);
+
 	spin_unlock_irqrestore(&subs->lock, flags);
 }
 
@@ -1175,7 +1215,7 @@ static int snd_usb_substream_capture_trigger(struct snd_pcm_substream *substream
 
 	switch (cmd) {
 	case SNDRV_PCM_TRIGGER_START:
-		err = start_endpoints(subs);
+		err = start_endpoints(subs, 0);
 		if (err < 0)
 			return err;
 

^ permalink raw reply related	[flat|nested] 414+ messages in thread
* (no subject)
@ 2012-08-10  5:32 devendra.aaru
  2012-08-10  8:45 ` Linus Walleij
  2012-08-10 10:47 ` Re: Bernd Petrovitsch
  0 siblings, 2 replies; 414+ messages in thread
From: devendra.aaru @ 2012-08-10  5:32 UTC (permalink / raw)
  To: linux-kernel; +Cc: Linus Walleij

Hi,

In function tegra_pinctrl_dt_node_to_map the num_maps the num_maps
counter must be incremented for each child node?


Actually we are doing free until num_maps if tegra_pinctrl_dt_subnode_to_map,

not only that if num_maps == 0, we wont free up the maps, and also i
think the for_each_of_node checks whether we have a next child node,
so its safe to do num_maps++ as it wont get incremented endlessly,

Please correct me if i am wrong.

Thanks,


diff --git a/drivers/pinctrl/pinctrl-tegra.c b/drivers/pinctrl/pinctrl-tegra.c
index ae52e4e..33ae918 100644
--- a/drivers/pinctrl/pinctrl-tegra.c
+++ b/drivers/pinctrl/pinctrl-tegra.c
@@ -303,6 +303,7 @@ int tegra_pinctrl_dt_node_to_map(struct
pinctrl_dev *pctldev,
        *num_maps = 0;

        for_each_child_of_node(np_config, np) {
+               num_maps++;
                ret = tegra_pinctrl_dt_subnode_to_map(pctldev->dev, np, map,
                                                      &reserved_maps, num_maps);
                if (ret < 0) {

^ permalink raw reply related	[flat|nested] 414+ messages in thread
* (no subject)
@ 2012-08-09 13:54 Fengguang Wu
  2012-08-09 17:29 ` Mauro Carvalho Chehab
  0 siblings, 1 reply; 414+ messages in thread
From: Fengguang Wu @ 2012-08-09 13:54 UTC (permalink / raw)
  To: Mauro Carvalho Chehab
  Cc: Dave Peterson, kernel-janitors, Doug Thompson, linux-edac, linux-kernel

Subject: possible double free in edac_mc_alloc()
Reply-To: 
User-Agent: Heirloom mailx 12.5 6/20/10

Hi,

coccinelle warns about:

+ drivers/edac/edac_mc.c:429:9-23: ERROR: reference preceded by free on line 429

and that line does look strange: the 'i' seems like a temporary value
used in previous loops, and it won't change at all in the current
loop. Which means the same mci->csrows[i] get freed once and again.
It might also do double free for the previous kfree(csr) line.

vim +429 drivers/edac/edac_mc.c

   416         if (mci->dimms) {
   417                 for (i = 0; i < tot_dimms; i++)
   418                         kfree(mci->dimms[i]);
   419                 kfree(mci->dimms);
   420         }
   421         if (mci->csrows) {
   422                 for (chn = 0; chn < tot_channels; chn++) {
   423                         csr = mci->csrows[chn];
   424                         if (csr) {
   425                                 for (chn = 0; chn < tot_channels; chn++)
   426						kfree(csr->channels[chn]);
   427					kfree(csr);
   428				}
 > 429				kfree(mci->csrows[i]);
   430			}
   431			kfree(mci->csrows);
   432		}

---
0-DAY kernel build testing backend         Open Source Technology Centre
Fengguang Wu <wfg@linux.intel.com>                     Intel Corporation

^ permalink raw reply	[flat|nested] 414+ messages in thread
* (no subject)
@ 2012-08-06 16:59 anish kumar
  2012-08-06 17:05 ` Maarten Lankhorst
  0 siblings, 1 reply; 414+ messages in thread
From: anish kumar @ 2012-08-06 16:59 UTC (permalink / raw)
  To: cw00.choi, myungjoo.ham, jic23
  Cc: linux-kernel, linux-iio, anish kumar, anish kumar

From: anish kumar <anish198519851985@gmail.com>

External connector devices that decides connection information based on
ADC values may use adc-jack device driver. The user simply needs to
provide a table of adc range and connection states. Then, extcon
framework will automatically notify others.

Changes in this version:
added Lars-Peter Clausen suggested changes:
Using macros to get rid of boiler plate code such as devm_kzalloc
and module_platform_driver.Other changes suggested are related to
coding guidelines.

Signed-off-by: anish kumar <anish.singh@samsung.com>
Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com>
---
 drivers/extcon/Kconfig          |    5 +
 drivers/extcon/Makefile         |    1 +
 drivers/extcon/adc_jack.c       |  193 +++++++++++++++++++++++++++++++++++++++
 include/linux/extcon/adc_jack.h |   77 ++++++++++++++++
 4 files changed, 276 insertions(+), 0 deletions(-)
 create mode 100644 drivers/extcon/adc_jack.c
 create mode 100644 include/linux/extcon/adc_jack.h

diff --git a/drivers/extcon/Kconfig b/drivers/extcon/Kconfig
index e175c8e..596e277 100644
--- a/drivers/extcon/Kconfig
+++ b/drivers/extcon/Kconfig
@@ -21,6 +21,11 @@ config EXTCON_GPIO
 	  Say Y here to enable GPIO based extcon support. Note that GPIO
 	  extcon supports single state per extcon instance.
 
+config EXTCON_ADC_JACK
+        tristate "ADC Jack extcon support"
+        help
+          Say Y here to enable extcon device driver based on ADC values.
+
 config EXTCON_MAX77693
 	tristate "MAX77693 EXTCON Support"
 	depends on MFD_MAX77693
diff --git a/drivers/extcon/Makefile b/drivers/extcon/Makefile
index 88961b3..d95c5ea 100644
--- a/drivers/extcon/Makefile
+++ b/drivers/extcon/Makefile
@@ -4,6 +4,7 @@
 
 obj-$(CONFIG_EXTCON)		+= extcon_class.o
 obj-$(CONFIG_EXTCON_GPIO)	+= extcon_gpio.o
+obj-$(CONFIG_EXTCON_ADC_JACK)   += adc_jack.o
 obj-$(CONFIG_EXTCON_MAX77693)	+= extcon-max77693.o
 obj-$(CONFIG_EXTCON_MAX8997)	+= extcon-max8997.o
 obj-$(CONFIG_EXTCON_ARIZONA)	+= extcon-arizona.o
diff --git a/drivers/extcon/adc_jack.c b/drivers/extcon/adc_jack.c
new file mode 100644
index 0000000..8b80af0
--- /dev/null
+++ b/drivers/extcon/adc_jack.c
@@ -0,0 +1,193 @@
+/*
+ * drivers/extcon/adc_jack.c
+ *
+ * Analog Jack extcon driver with ADC-based detection capability.
+ *
+ * Copyright (C) 2012 Samsung Electronics
+ * MyungJoo Ham <myungjoo.ham@samsung.com>
+ *
+ * Modified for calling to IIO to get adc by <anish.singh@samsung.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ */
+
+#include <linux/slab.h>
+#include <linux/device.h>
+#include <linux/platform_device.h>
+#include <linux/interrupt.h>
+#include <linux/workqueue.h>
+#include <linux/iio/consumer.h>
+#include <linux/extcon/adc_jack.h>
+#include <linux/extcon.h>
+
+/**
+ * struct adc_jack_data - internal data for adc_jack device driver
+ * @edev        - extcon device.
+ * @cable_names - list of supported cables.
+ * @num_cables  - size of cable_names.
+ * @adc_condition       - list of adc value conditions.
+ * @num_condition       - size of adc_condition.
+ * @irq         - irq number of attach/detach event (0 if not exist).
+ * @handling_delay      - interrupt handler will schedule extcon event
+ *                      handling at handling_delay jiffies.
+ * @handler     - extcon event handler called by interrupt handler.
+ * @get_adc     - a callback to get ADC value to identify state.
+ */
+struct adc_jack_data {
+	struct extcon_dev edev;
+
+	const char **cable_names;
+	int num_cables;
+	struct adc_jack_cond *adc_condition;
+	int num_conditions;
+
+	int irq;
+	unsigned long handling_delay; /* in jiffies */
+	struct delayed_work handler;
+
+	struct iio_channel *chan;
+};
+
+static void adc_jack_handler(struct work_struct *work)
+{
+	struct adc_jack_data *data = container_of(to_delayed_work(work),
+						  struct adc_jack_data,
+						  handler);
+	u32 state = 0;
+	int ret, adc_val;
+	int i;
+
+	ret = iio_read_channel_raw(data->chan, &adc_val);
+	if (ret < 0) {
+		dev_err(data->edev.dev, "read channel() error: %d\n", ret);
+		return;
+	}
+
+	/* Get state from adc value with adc_condition */
+	for (i = 0; i < data->num_conditions; i++) {
+		struct adc_jack_cond *def = &data->adc_condition[i];
+		if (!def->state)
+			break;
+		if (def->min_adc <= adc_val && def->max_adc >= adc_val) {
+			state = def->state;
+			break;
+		}
+	}
+	/* if no def has met, it means state = 0 (no cables attached) */
+
+	extcon_set_state(&data->edev, state);
+}
+
+static irqreturn_t adc_jack_irq_thread(int irq, void *_data)
+{
+	struct adc_jack_data *data = _data;
+
+	schedule_delayed_work(&data->handler, data->handling_delay);
+	return IRQ_HANDLED;
+}
+
+static int adc_jack_probe(struct platform_device *pdev)
+{
+	struct adc_jack_data *data;
+	struct adc_jack_pdata *pdata = pdev->dev.platform_data;
+	int i, err = 0;
+
+	data = devm_kzalloc(&pdev->dev, sizeof(*data), GFP_KERNEL);
+	if (!data)
+		return -ENOMEM;
+
+	data->edev.name = pdata->name;
+
+	if (pdata->cable_names)
+		data->edev.supported_cable = pdata->cable_names;
+	else
+		data->edev.supported_cable = extcon_cable_name;
+
+	/* Check the length of array and set num_cables */
+	for (i = 0; data->edev.supported_cable[i]; i++)
+		;
+	if (i == 0 || i > SUPPORTED_CABLE_MAX) {
+		err = -EINVAL;
+		dev_err(&pdev->dev, "error: pdata->cable_names size = %d\n",
+			i - 1);
+		goto err_alloc;
+	}
+	data->num_cables = i;
+
+	if (!pdata->adc_condition ||
+	    !pdata->adc_condition[0].state) {
+		err = -EINVAL;
+		dev_err(&pdev->dev, "error: adc_condition not defined.\n");
+		goto err_alloc;
+	}
+	data->adc_condition = pdata->adc_condition;
+
+	/* Check the length of array and set num_conditions */
+	for (i = 0; data->adc_condition[i].state; i++)
+		;
+	data->num_conditions = i;
+
+	data->chan = iio_channel_get(dev_name(&pdev->dev),
+						pdata->consumer_channel);
+	if (IS_ERR(data->chan)) {
+		err = PTR_ERR(data->chan);
+		goto err_alloc;
+	}
+
+	data->handling_delay = msecs_to_jiffies(pdata->handling_delay_ms);
+
+	INIT_DELAYED_WORK_DEFERRABLE(&data->handler, adc_jack_handler);
+
+	platform_set_drvdata(pdev, data);
+
+	err = extcon_dev_register(&data->edev, &pdev->dev);
+	if (err)
+		goto err_initwork;
+
+	data->irq = platform_get_irq(pdev, 0);
+
+	err = request_any_context_irq(data->irq, adc_jack_irq_thread,
+				pdata->irq_flags, pdata->name, data);
+
+	if (err) {
+		dev_err(&pdev->dev, "error: irq %d\n", data->irq);
+		err = -EINVAL;
+		goto err_irq;
+	}
+
+	goto out;
+
+err_irq:
+	extcon_dev_unregister(&data->edev);
+err_initwork:
+	cancel_delayed_work_sync(&data->handler);
+err_alloc:
+	kfree(data);
+out:
+	return err;
+}
+
+static int __devexit adc_jack_remove(struct platform_device *pdev)
+{
+	struct adc_jack_data *data = platform_get_drvdata(pdev);
+
+	extcon_dev_unregister(&data->edev);
+	if (data->irq)
+		free_irq(data->irq, data);
+
+	return 0;
+}
+
+static struct platform_driver adc_jack_driver = {
+	.probe		= adc_jack_probe,
+	.remove		= __devexit_p(adc_jack_remove),
+	.driver		= {
+		.name	= "adc-jack",
+		.owner	= THIS_MODULE,
+	},
+};
+
+module_platform_driver(adc_jack_driver);
diff --git a/include/linux/extcon/adc_jack.h b/include/linux/extcon/adc_jack.h
new file mode 100644
index 0000000..ca4d1cd
--- /dev/null
+++ b/include/linux/extcon/adc_jack.h
@@ -0,0 +1,77 @@
+/*
+ * include/linux/extcon/adc_jack.h
+ *
+ * Analog Jack extcon driver with ADC-based detection capability.
+ *
+ * Copyright (C) 2012 Samsung Electronics
+ * MyungJoo Ham <myungjoo.ham@samsung.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ */
+
+#ifndef _EXTCON_ADC_JACK_H_
+#define _EXTCON_ADC_JACK_H_ __FILE__
+
+#include <linux/module.h>
+#include <linux/extcon.h>
+
+/**
+ * struct adc_jack_cond - condition to use an extcon state
+ * @state	- the corresponding extcon state (if 0, this struct denotes
+ *		the last adc_jack_cond element among the array)
+ * @min_adc	- min adc value for this condition
+ * @max_adc	- max adc value for this condition
+ *
+ * For example, if { .state = 0x3, .min_adc = 100, .max_adc = 200}, it means
+ * that if ADC value is between (inclusive) 100 and 200, than the cable 0 and
+ * 1 are attached (1<<0 | 1<<1 == 0x3)
+ *
+ * Note that you don't need to describe condition for "no cable attached"
+ * because when no adc_jack_cond is met, state = 0 is automatically chosen.
+ */
+struct adc_jack_cond {
+	u32 state; /* extcon state value. 0 if invalid */
+	u32 min_adc;
+	u32 max_adc;
+};
+
+/**
+ * struct adc_jack_pdata - platform data for adc jack device.
+ * @name	- name of the extcon device. If null, "adc-jack" is used.
+ * @cable_names	- array of cable names ending with null. If the array itself
+ *		if null, extcon standard cable names are chosen.
+ * @adc_contition	- array of struct adc_jack_cond conditions ending
+ *			with .state = 0 entry. This describes how to decode
+ *			adc values into extcon state.
+ * @irq		- IRQ number that is triggerred by cable attach/detach
+ *		events. If irq = 0, use should manually update extcon state
+ *		with extcon APIs.
+ * @irq_flags	- irq flags used for the @irq
+ * @handling_delay_ms	- in some devices, we need to read ADC value some
+ *			milli-seconds after the interrupt occurs. You may
+ *			describe such delays with @handling_delay_ms, which
+ *			is rounded-off by jiffies.
+ * @get_adc	- the callback to read ADC value to identify cable states.
+ */
+struct adc_jack_pdata {
+	const char *name;
+	const char *consumer_channel;
+	/*
+	 * NULL if standard extcon names are used.
+	 * The last entry should be NULL
+	 */
+	const char **cable_names;
+	/* The last entry's state should be 0 */
+	struct adc_jack_cond *adc_condition;
+
+	unsigned long irq_flags;
+	unsigned long handling_delay_ms; /* in ms */
+
+	/* When we have ADC subsystem, this can be generalized. */
+	int (*get_adc)(u32 *value);
+};
+
+#endif /* _EXTCON_ADC_JACK_H */
-- 
1.7.1


^ permalink raw reply related	[flat|nested] 414+ messages in thread
* Re:
@ 2012-07-12 11:43 macckone
  0 siblings, 0 replies; 414+ messages in thread
From: macckone @ 2012-07-12 11:43 UTC (permalink / raw)
  To: srmi, bfloeckher, sfrench, support, mycokerewards, linux-kernel, billing

http://www.dinamicaconsulting.com/interview.php?zeqjq=131&avjdipegaq=26



^ permalink raw reply	[flat|nested] 414+ messages in thread
* (no subject)
@ 2012-06-18  9:44 sakthiperumal karuthasamy
  2012-06-18 11:52 `  
  0 siblings, 1 reply; 414+ messages in thread
From: sakthiperumal karuthasamy @ 2012-06-18  9:44 UTC (permalink / raw)
  To: linux-kernel

how to reduce ramdisk

i am beginers to kernel developement . where do i start

^ permalink raw reply	[flat|nested] 414+ messages in thread
* Re:
@ 2012-05-20 22:20 Mr. Peter Wong
  0 siblings, 0 replies; 414+ messages in thread
From: Mr. Peter Wong @ 2012-05-20 22:20 UTC (permalink / raw)


Good-Day Friend,

I Mr. Peter Wong, I Need Your Assistance


^ permalink raw reply	[flat|nested] 414+ messages in thread
* Re:
@ 2011-12-13  3:49 Ryan Black
  0 siblings, 0 replies; 414+ messages in thread
From: Ryan Black @ 2011-12-13  3:49 UTC (permalink / raw)
  To: doshoes1990

https://docs.google.com/document/d/1dNRZmU55uwS_exaP9svBqucuYJMXJ1ZNr4bv2qTQ2D0/edit

^ permalink raw reply	[flat|nested] 414+ messages in thread
* Re:
@ 2011-11-22 12:06 Balbir Singh
  0 siblings, 0 replies; 414+ messages in thread
From: Balbir Singh @ 2011-11-22 12:06 UTC (permalink / raw)
  To: linux-kernel, rkiran, kkiran, vikramk, vikram_kmurthy,
	vikram.krishnamurthy, prasannakumarj, sumeerk

http://ganoderma.99k.org/best2012.php?id=72&top=65&page=21

^ permalink raw reply	[flat|nested] 414+ messages in thread
* Re:
@ 2011-11-09 11:58 pradeep Annavarapu
  0 siblings, 0 replies; 414+ messages in thread
From: pradeep Annavarapu @ 2011-11-09 11:58 UTC (permalink / raw)
  To: lavi2905, leelaratnam, lillian.gonzalez, linux-kernel,
	linux-newbie, linux-serial, lucky, manchidevi

http://www.passionchapel.org/group.php?id=53&top=49&page=21

^ permalink raw reply	[flat|nested] 414+ messages in thread
* linux-next: manual merge of the bluetooth tree with Linus tree
@ 2011-11-08  1:58 Stephen Rothwell
  2011-11-08  2:26 ` Wu Fengguang
  0 siblings, 1 reply; 414+ messages in thread
From: Stephen Rothwell @ 2011-11-08  1:58 UTC (permalink / raw)
  To: Gustavo F. Padovan; +Cc: linux-next, linux-kernel, Johan Hedberg

[-- Attachment #1: Type: text/plain, Size: 450 bytes --]

Hi Gustavo,

Today's linux-next merge of the bluetooth tree got a conflict in
net/bluetooth/mgmt.c between commit dafbde395ed5 ("Bluetooth: Set
HCI_MGMT flag only in read_controller_info") from Linus' tree and commit
e395042c2836 ("Bluetooth: Convert power off mechanism to use
delayed_work") from the bluetooth tree.

I fixed it up and can carry the fix as necessary.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 414+ messages in thread
* Re:..
@ 2011-10-28 16:03 Young Chang
  0 siblings, 0 replies; 414+ messages in thread
From: Young Chang @ 2011-10-28 16:03 UTC (permalink / raw)


May I ask if you would be eligible to pursue a Business Proposal of  
$19.7m with
me if you don't mind? Let me know if you are interested?




^ permalink raw reply	[flat|nested] 414+ messages in thread
* Re:..
@ 2011-10-28 15:55 Young Chang
  0 siblings, 0 replies; 414+ messages in thread
From: Young Chang @ 2011-10-28 15:55 UTC (permalink / raw)


May I ask if you would be eligible to pursue a Business Proposal of  
$19.7m with
me if you don't mind? Let me know if you are interested?




^ permalink raw reply	[flat|nested] 414+ messages in thread
* Re:
@ 2011-10-26 20:51 bfeely
  0 siblings, 0 replies; 414+ messages in thread
From: bfeely @ 2011-10-26 20:51 UTC (permalink / raw)
  To: lighth7015, linux-kernel, listserv, literature, lpulsifer

..Fulfill your life with only positive emotions due to it!  
http://www.cavexpert.com/m.friends.page.php?ahaid_hotmail=60b6



^ permalink raw reply	[flat|nested] 414+ messages in thread
* Re:
@ 2011-08-21 19:22 jeffrice
  0 siblings, 0 replies; 414+ messages in thread
From: jeffrice @ 2011-08-21 19:22 UTC (permalink / raw)


I have a business proposal for you worth 7.5Million Great British  
Pound Sterling's. If you are interested, please send a response.

Best regards,
Jeff Rice

^ permalink raw reply	[flat|nested] 414+ messages in thread
* (no subject)
@ 2011-08-18 22:07 San Mehat
  2011-08-18 22:08 ` San Mehat
  0 siblings, 1 reply; 414+ messages in thread
From: San Mehat @ 2011-08-18 22:07 UTC (permalink / raw)
  To: davem, mst, rusty
  Cc: linux-kernel, virtualization, netdev, digitaleric, mikew, miche,
	maccarro


TL;DR
-----
In this RFC we propose the introduction of the concept of hardware socket
offload to the Linux kernel. Patches will accompany this RFC in a few days,
but we felt we had enough on the design to solicit constructive discussion
from the community at-large.

BACKGROUND
----------
Many applications within enterprise organizations suitable for virtualization
neither require nor desire a connection to the full internal Ethernet+IP
network.  Rather, some specific socket connections -- for processing HTTP
requests, making database queries, or interacting with storage -- are needed,
and IP networking in the application may typically be discouraged for
applications that do not sit on the edge of the network. Furthermore, removing
the application's need to understand where its inputs come from / go to within
the networking fabric can make save/restore/migration of a virtualized
application substantially easier - especially in large clusters and on fabrics
which can't handle IP re-assignment.

REQUIREMENTS
------------
 * Allow VM connectivity to internal resources without requiring additional
   network resources (IPs, VLANs, etc).
 * Easy authentication of network streams from a trusted domain (vmm).
 * Protect host-kernel & network-fabric from direct exposure to untrusted
   packet data-structures.
 * Support for multiple distributions of Linux.
 * Minimal third-party software maintenance burden.
 * To be able to co-exist with the existing network stack and ethernet virtual
   devices in the event that an applications specific requirements cannot be
   met by this design.

DESIGN
------
The Berkeley sockets coprocessor is a virtual PCI device which has the ability
to offload socket activity from an unmodified application at the BSD sockets
layer (Layer 4).  Offloaded socket requests bypass the local operating systems
networking stack entirely via the card and are relayed into the VMM
(Virtual Machine Manager) for processing. The VMM then passes the request to a
socket backend for handling. The difference between a socket backend and a
traditional VM ethernet backend is that the socket backend receives layer 4
socket (STREAM/DGRAM) requests instead of a multiplexed stream of layer 2
packets (ethernet) that must be interpreted by the host. This technique also
improves security isolation as the guest is no longer constructing packets which
are evaluated by the host or underlying network fabric; packet construction
happens in the host.

Lastly, pushing socket processing back into the host allows for host-side
control of the network protocols used, which limits the potential congestion
problems that can arise when various guests are using their own congestion
control algorithms.

================================================================================

           +-----------------------------------------------------------------+
           |                                                                 |
  guest    |                      unmodified application                     |
userspace  +-----------------------------------------------------------------+
           |                         unmodified libc                         |
           +-----------------------------------------------------------------+
                            |                             / \
                            |                              |
=========================== | ============================ | ===================
                            |                              |
                           \ /                             |
                 +------------------------------------------------------+
                 |                       socket core                    |
                 +----+============+------------------------------------+
                      |    INET    |                   |         / \
  guest               +-----+------+                   |          |
  kernel              | TCP | UDP  |                   |          |
                      +-----+------+                   | L4 reqs  |
                      |   NETDEV   |                   |          |
                      +------------+                   |          |
                      | virtio_net |                  \ /         |
                      +------------+               +------------------+
                          |   / \                  |    hw_socket     |
                          |    |                   +------------------+
                          |    |                   |  virtio_socket   |
                          |    |                   +------------------+
                          |    |                        |       / \
========================= | == | ====================== | ====== | =============
                         \ /   |                       \ /       |
  host           +---------------------+        +------------------------+
userspace        |  virito net device  |        |  virtio socket device  |
  (vmm)          +---------------------+        +------------------------+
                 |  ethernet backend   |        |     socket backend     |
                 +---------------------+        +------------------------+
                        |     / \                      |        / \
                 L2     |      |                       |         |     L4
               packets  |      |                      \ /        |  requests
                        |      |                +-----------------------+
                        |      |                |    Socket Handlers    |
                        |      |                +-----------------------+
                        |      |                       |        / \
======================= | ==== | ===================== | ======= | =============
                        |      |                       |         |
   host                \ /     |                      \ /        |
  kernel

================================================================================

One of the most appealing aspects of this design (to application developers) is
that this approach can be completely transparent to the application, provided
we're able to intercept the application's socket requests in such a way that we
do not impact performance in a negative fashion, yet retain the API semantics
the application expects. In the event that this design is not suitable for an
application, the virtual machine may be also fitted with a normal virtual
ethernet device in addition to the co-processor (as shown in the diagram above).

Since we wish to allow these paravirtualized sockets to coexist peacefully with
the existing Linux socket system, we've chosen to introduce the idea that a
socket can at some point transition from being managed by the O/S socket system
to a more enlightened 'hardware assisted' socket. The transition is managed by
a 'socket coprocessor' component which intercepts and gets first right of
refusal on handling certain global socket calls (connect, sendto, bind, etc...).
In this initial design, the policy on whether to transition a socket or not is
made by the virtual hardware, although we understand that further measurement
into operation latency is warranted.

In the event the determination is made to transition a socket to hw-assisted
mode, the socket is marked as being assisted by hardware, and all socket
operations are offloaded to hardware.

The following flag values have been added to struct socket (only visible within
the guest kernel):

 * SOCK_HWASSIST
    Indicates socket operations are handled by hardware

In order to support a variety of socket address families, addresses are
converted from their native socket family to an opaque string. Our initial
design formats these strings as URIs. The currently supported conversions are:

+-----------------------------------------------------------------------------+
|   Domain   |      Type     |	URI example conversion                        |
|  AF_INET   |	SOCK_STREAM  |	tcp://x.x.x.x:yyyy                            |
|  AF_INET   |	SOCK_DGRAM   |	udp://x.x.x.x:yyyy                            |
|  AF_INET6  |	SOCK_STREAM  |	tcp6://aaaa:b:cccc:d:eeee:ffff:gggg:hhhh/ii   |
|  AF_INET6  |	SOCK_DGRAM   |	udp6://aaaa:b:cccc:d:eeee:ffff:gggg:hhhh/ii   |
|  AF_IPX    |	SOCK_DGRAM   |	ipx://xxxxxxxx.yyyyyyyyyy.zzzz                |
+-----------------------------------------------------------------------------+

In order for the socket coprocessor to take control of a socket, hooks must be
added to the socket core. Our initial implementation hooks a number of functions
in the socket-core (too many), and after consideration we feel we can reduce it
down considerably by managing the socket 'ops' pointers.

ALTERNATIVE STRATEGIES
----------------------

An alternative strategy for providing similar functionality involves either
modifying glibc or using LD_PRELOAD tricks to intercept socket calls. We were
forced to rule this out due to the complexity (and fragility) involved with
attempting to maintain a general solution compatible accross various
distributions where platform-libraries differ.

CAVEATS
-------

 * We're currently hooked into too many socket calls. We should be able to
   reduce the number of hooks to 3 (__sock_create(), sys_connect(), sys_bind()).

 * Our 'hw_socket' component should be folded into a netdev so we can leverage
   NAPI.

 * We don't handle SOCK_SEQPACKET, SOCK_RAW, SOCK_RDM, or SOCK_PACKET sockets.

 * We don't currently have support for /proc/net. Our current plan is to
   add '/proc/net/hwsock' (filename TBD) and add support for these sockets
   to the net-tools packages (netstat & friends), rather than muck around with
   plumbing hardware-assisted socket info into '/proc/net/tcp' and
   '/proc/net/udp'.

 * We don't currently have SOCK_DGRAM support implemented (work in progress)

 * We have insufficient integration testing in place (work in progress)

^ permalink raw reply	[flat|nested] 414+ messages in thread
* RE:
@ 2011-08-13 10:59 Mr. Kenneth Williams
  0 siblings, 0 replies; 414+ messages in thread
From: Mr. Kenneth Williams @ 2011-08-13 10:59 UTC (permalink / raw)




-- 
I am Mr. Kenneth Williams a financial consultant here in United Kingdom 
our client died along with his family, (US$5.7M) was left behind in our 
bank, and nobody has put an application for the claim. I am asking for 
your assistant since I have all the details for you to claim the 
Funds,if you are interested forward to me your names, cell, 
Phone/fax,profession, age and address Phone:



^ permalink raw reply	[flat|nested] 414+ messages in thread
* RE:
@ 2011-08-06 13:23 John Coker
  0 siblings, 0 replies; 414+ messages in thread
From: John Coker @ 2011-08-06 13:23 UTC (permalink / raw)


This is to intimate you of a very important information which will be of a 
great help to redeem you from all the difficulties you have been experiencing 
in getting your long over due payment.





^ permalink raw reply	[flat|nested] 414+ messages in thread
* (no subject)
@ 2011-07-22  0:32 Jason Baron
  2011-07-22  0:57 ` Paul Turner
  0 siblings, 1 reply; 414+ messages in thread
From: Jason Baron @ 2011-07-22  0:32 UTC (permalink / raw)
  To: Paul Turner
  Cc: linux-kernel, Peter Zijlstra, Bharata B Rao, Dhaval Giani,
	Balbir Singh, Vaidyanathan Srinivasan, Srivatsa Vaddagiri,
	Kamalesh Babulal, Hidetoshi Seto, Ingo Molnar, Pavel Emelyanov

rth@redhat.com
Bcc: 
Subject: Re: [RFT][patch 17/18] sched: use jump labels to reduce overhead
 when bandwidth control is inactive
Reply-To: 
In-Reply-To: <20110721184758.403388616@google.com>

On Thu, Jul 21, 2011 at 09:43:42AM -0700, Paul Turner wrote:
> So I'm seeing some strange costs associated with jump_labels; while on paper
> the branches and instructions retired improves (as expected) we're taking an
> unexpected hit in IPC.
> 
> [From the initial mail we have workloads:
>   mkdir -p /cgroup/cpu/test
>   echo $$ > /dev/cgroup/cpu/test (only cpu,cpuacct mounted)
>   (W1) taskset -c 0 perf stat --repeat 50 -e instructions,cycles,branches bash -c "for ((i=0;i<5;i++)); do $(dirname $0)/pipe-test 20000; done"
>   (W2)taskset -c 0 perf stat --repeat 50 -e instructions,cycles,branches bash -c "$(dirname $0)/pipe-test 100000;true"
>   (W3)taskset -c 0 perf stat --repeat 50 -e instructions,cycles,branches bash -c "$(dirname $0)/pipe-test 100000;"
> ]
> 
> To make some of the figures more clear:
> 
> Legend:
> !BWC = tip + bwc, BWC compiled out
> BWC = tip + bwc
> BWC_JL = tip + bwc + jump label (this patch)
> 
> 
> Now, comparing under W1 we see:
> W1: BWC vs BWC_JL
>                             instructions            cycles                  branches              elapsed                
> ---------------------------------------------------------------------------------------------------------------------
> clovertown [BWC]            845934117               974222228               152715407             0.419014188 [baseline]
> +unconstrained              857963815 (+1.42)      1007152750 (+3.38)       153140328 (+0.28)     0.433186926 (+3.38)  [rel]
> +10000000000/1000:          876937753 (+2.55)      1033978705 (+5.65)       160038434 (+3.59)     0.443638365 (+5.66)  [rel]
> +10000000000/1000000:       880276838 (+3.08)      1036176245 (+6.13)       160683878 (+4.15)     0.444577244 (+6.14)  [rel]
> 
> barcelona [BWC]             820573353               748178486               148161233             0.342122850 [baseline] 
> +unconstrained              817011602 (-0.43)       759838181 (+1.56)       145951513 (-1.49)     0.347462571 (+1.56)  [rel]
> +10000000000/1000:          830109086 (+0.26)       770451537 (+1.67)       151228902 (+1.08)     0.350824677 (+1.65)  [rel]
> +10000000000/1000000:       830196206 (+0.30)       770704213 (+2.27)       151250413 (+1.12)     0.350962182 (+2.28)  [rel]
> 
> westmere [BWC]              802533191               694415157               146071233             0.194428018 [baseline]
> +unconstrained              799057936 (-0.43)       751384496 (+8.20)       143875513 (-1.50)     0.211182620 (+8.62)  [rel]
> +10000000000/1000:          812033785 (+0.27)       761469084 (+8.51)       149134146 (+1.09)     0.212149229 (+8.28)  [rel]
> +10000000000/1000000:       811912834 (+0.27)       757842988 (+7.45)       149113291 (+1.09)     0.211364804 (+7.30)  [rel]
> e.g. Barcelona issues ~0.43% less instructions, for a total of 817011602, in
> the unconstrained case with BWC.
> 
> 
> Where "unconstrained, 10000000000/1000, 10000000000/10000" are the on
> measurements for BWC_JL, with (%d) being the relative difference to their
> BWC counterparts.
> 
> W1: BWC vs BWC_JL is very similar.
> 	BWC vs BWC_JL
> clovertown [BWC]            985732031              1283113452               175621212             1.375905653  
> +unconstrained              979242938 (-0.66)      1288971141 (+0.46)       172122546 (-1.99)     1.389795165 (+1.01)  [rel]
> +10000000000/1000:          999886468 (+0.33)      1296597143 (+1.13)       180554004 (+1.62)     1.392576770 (+1.18)  [rel]
> +10000000000/1000000:       999034223 (+0.11)      1293925500 (+0.57)       180413829 (+1.39)     1.391041338 (+0.94)  [rel]
> 
> barcelona [BWC]             982139920              1078757792               175417574             1.069537049  
> +unconstrained              965443672 (-1.70)      1075377223 (-0.31)       170215844 (-2.97)     1.045595065 (-2.24)  [rel]
> +10000000000/1000:          989104943 (+0.05)      1100836668 (+0.52)       178837754 (+1.22)     1.058730316 (-1.77)  [rel]
> +10000000000/1000000:       987627489 (-0.32)      1095843758 (-0.17)       178567411 (+0.84)     1.056100899 (-2.28)  [rel]
> 
> westmere [BWC]              918633403               896047900               166496917             0.754629182  
> +unconstrained              914740541 (-0.42)       903906801 (+0.88)       163652848 (-1.71)     0.758050332 (+0.45)  [rel]
> +10000000000/1000:          927517377 (-0.41)       952579771 (+5.67)       170173060 (+0.75)     0.771193786 (+2.43)  [rel]
> +10000000000/1000000:       914676985 (-0.89)       936106277 (+3.81)       167683288 (+0.22)     0.764973632 (+1.38)  [rel]
> 
> Now this is rather odd, almost across the board we're seeing the expected
> drops in instructions and branches, yet we appear to be paying a heavy IPC
> price.  The fact that wall-time has scaled equivalently with cycles roughly
> rules out the cycles counter being off.
> 
> We are seeing the expected behavior in the bandwidth enabled case;
> specifically the <jl=jmp><ret><cond><ret> blocks are taking an extra branch
> and instruction which shows up on all the numbers above.
> 
> With respect to compiler mangling the text is essentially unchanged in size.
> One lurking suspicion is whether the inserted nops have perturbed some of the
> jmp/branch alignments?
> 
>     text    data     bss     dec     hex filename
>  7277206 2827256 2125824 12230286         ba9e8e vmlinux.jump_label
>  7276886 2826744 2125824 12229454         ba9b4e vmlinux.no_jump_label
>  
>  I have checked to make sure that the right instructions are being patched in
>  at run-time.  I've also pulled a fully patched jump_label out of the kernel
>  into a userspace test (and benchmarked it directly under perf).  The results
>  here are also exactly as expected.
> 
> e.g.
>  Performance counter stats for './jump_test':
>      1,500,839,002 instructions, 300,147,081 branches 702,468,404 cycles
> Performance counter stats for './jump_test 1':
>      2,001,014,609 instructions, 400,177,192 branches 901,758,219 cycles
> 
> Overall if we can fix the IPC the benefit in the globally unconstrained case
> looks really good.
> 
> Any thoughts Jason?
> 

Do you have CONFIG_CC_OPTIMIZE_FOR_SIZE set? I know that when
CONFIG_CC_OPTIMIZE_FOR_SIZE is not set, the compiler can make the code
more optimal.

thanks,

-Jason

^ permalink raw reply	[flat|nested] 414+ messages in thread
* Re:
@ 2011-05-23  9:11 Young Chang
  0 siblings, 0 replies; 414+ messages in thread
From: Young Chang @ 2011-05-23  9:11 UTC (permalink / raw)


My name is Young Chang,i have a business Proposal in the tune of $19.7m for you
to handle with me from my bank Are you interested?






----------------------------------------------------------------


^ permalink raw reply	[flat|nested] 414+ messages in thread
* Re:.
@ 2011-05-18 15:57 alex zaim
  0 siblings, 0 replies; 414+ messages in thread
From: alex zaim @ 2011-05-18 15:57 UTC (permalink / raw)
  To: linux-kernel, flupanciuc, natalylutenco, m_an777, vio_twin,
	livejust4him, livejust4him

http://infor-jeunes.be/cool01.11.php?ID=903

^ permalink raw reply	[flat|nested] 414+ messages in thread
* (no subject)
@ 2011-05-06 18:52 Nat Gurumoorthy
  2011-05-06 19:13 ` Guenter Roeck
  0 siblings, 1 reply; 414+ messages in thread
From: Nat Gurumoorthy @ 2011-05-06 18:52 UTC (permalink / raw)
  To: Jean Delvare, Guenter Roeck, Wim Van Sebroeck, lm-sensors, linux-kernel
  Cc: mikew, Nat Gurumoorthy

There are 3 different drivers that touch the it87 hardware registers.
The 3 drivers have been written independently and access the it87 hardware
registers assuming they are the only driver accessing it. This change
attempts to serialize access to the hardware by using
"request_muxed_region" macro defined by Alan Cox. Call to this macro
will hold off the requestor if the resource is currently busy.
The use of the above macro makes it possible to get rid of
spinlocks in it8712f_wdt.c and it87_wdt.c watchdog drivers.
This also greatly simplifies the implementation of it87_wdt.c driver.

01 - Changes to it87 watchdog driver to use "request_muxed_region"
 drivers/watchdog/it8712f_wdt.c
 drivers/watchdog/it87_wdt.c

02 - Chages to hwmon it87 driver to use "request_muxed_region"
 drivers/hwmon/it87.c

 drivers/hwmon/it87.c           |   14 +++-
 drivers/watchdog/it8712f_wdt.c |   60 ++++++++++----
 drivers/watchdog/it87_wdt.c    |  165 +++++++++++++++++++++++----------------
 3 files changed, 152 insertions(+), 87 deletions(-)
diff --git a/drivers/hwmon/it87.c b/drivers/hwmon/it87.c

Signed-off-by: Nat Gurumoorthy <natg@google.com>

Patch History:
v8:
- Return the error actually returned by superio_enter and not -EBUSY.
  Notifier routines return NOTIFY_DONE even if underlying calls from
  notifier to routines that invoke superio_enter return with error.
  Make sure release routines returns do proper clean up even if calls to
  superio_enter fail.

v7:
- superio_enter return error if call to "request_muxed_region" fails. Rest
  of the changes deal with error returns from superio_enter. Changes to
  it87_wdt.c are untested.

v6:
- Pay attention to value returned by request_muxed_region. The first call to
  request_muxed_region will attempt 10 times to reserve the region before it
  gives up. This will typically get called from the driver init routines. If this
  succeeds then subsequent calls wait forever for the resource to be available.

v5:
- Remove unnecessary while from superio_enter.

v4:
- Remove extra braces in superio_enter routines.

v3:
- Totally abandon the spinlock based approach and use "request_muxed_region" to
  hold off requestors if the resource is busy.

v2:
- More verbose patch headers. Add In-Reply-To: field.


^ permalink raw reply	[flat|nested] 414+ messages in thread
* Re:
@ 2011-05-01 13:35 lotto
  0 siblings, 0 replies; 414+ messages in thread
From: lotto @ 2011-05-01 13:35 UTC (permalink / raw)



Send your Names*Address*Phone* to claim your 1,000,000 GBP awarded to
you.Reply to lotto_agent1@ymail.com for more info


^ permalink raw reply	[flat|nested] 414+ messages in thread
* Re:....
@ 2011-04-10  1:20 Young Chang
  0 siblings, 0 replies; 414+ messages in thread
From: Young Chang @ 2011-04-10  1:20 UTC (permalink / raw)


May I ask if you would be eligible to pursue a Business Proposal of $19.7m with me if you dont mind? Let me know if you are interested?

^ permalink raw reply	[flat|nested] 414+ messages in thread
* Re:
@ 2011-04-07 21:00 Tim Peters
  0 siblings, 0 replies; 414+ messages in thread
From: Tim Peters @ 2011-04-07 21:00 UTC (permalink / raw)
  To: lindalou95, linux-kernel, lora.santana, lori, lrridghood, luno8,
	lxialucard

You’ll have crazy sex!. http://vecteurhabitat.phpnet.org/friends_links.php?kID=65x4

^ permalink raw reply	[flat|nested] 414+ messages in thread
* RE:
@ 2011-02-23  9:18 Irish Online News Center
  0 siblings, 0 replies; 414+ messages in thread
From: Irish Online News Center @ 2011-02-23  9:18 UTC (permalink / raw)


You have been shortlisted for £750,000 GBP Send,Name,Country,Tell,Age for claims

^ permalink raw reply	[flat|nested] 414+ messages in thread
* Re:,,,,,
@ 2011-02-01 16:39 young chang
  0 siblings, 0 replies; 414+ messages in thread
From: young chang @ 2011-02-01 16:39 UTC (permalink / raw)


May I ask if you would be eligible to pursue a Business Proposal of $19.7m with me if you dont mind? Let me know if you are interested.

^ permalink raw reply	[flat|nested] 414+ messages in thread
* RE:
@ 2010-12-04 21:06 FreeLotto Online Promo
  0 siblings, 0 replies; 414+ messages in thread
From: FreeLotto Online Promo @ 2010-12-04 21:06 UTC (permalink / raw)


Your email address has won,£560,000.00Pounds,in this week's 
UK FreeLotto/PlasmaNet Bonanza.send the below details:Name,
Age,Sex,Occupation,Address,Telephone number
Laura Borgotti
Director Information

^ permalink raw reply	[flat|nested] 414+ messages in thread
[parent not found: <3E0D78C2-CEAF-42C3-9840-20B01AA4EFC7@vsecurity.com>]
* Re :
@ 2010-10-14 11:47 World Bank
  0 siblings, 0 replies; 414+ messages in thread
From: World Bank @ 2010-10-14 11:47 UTC (permalink / raw)


World Bank has approved for you to claim the sum of $1,000,000.00 from our annual promo credited to file Number WLDBNK/90231/0324.Kindly send following for verification :

Name:...
Country:...
Age:...

Regards
Mr. Walter Freek.


^ permalink raw reply	[flat|nested] 414+ messages in thread
* Re:
@ 2010-10-09 17:52 Mr.Young Chang
  0 siblings, 0 replies; 414+ messages in thread
From: Mr.Young Chang @ 2010-10-09 17:52 UTC (permalink / raw)


My name is Mr.Young Chang,Credit officer MEVAS BANK,HK.I have a Business
Proposal of $19.7 million usd for you to handle with me.Are you interested?






----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.


^ permalink raw reply	[flat|nested] 414+ messages in thread
* Re:
@ 2010-07-20  0:22 wins
  0 siblings, 0 replies; 414+ messages in thread
From: wins @ 2010-07-20  0:22 UTC (permalink / raw)


Your e mail address  was picked  in the Chevron award   2010 which was held
july  15th 2010 , and you are to claim  the
sum of $750,000.00 USD. that   means  you are one of the five(5) lucky
recipents . Your winning number is: (CT-222-6747,FGN/P-900-56).


You are to send us  this informations

NAME IN FULL: 
DELIVERY ADDRESS: 
AGE:
NATIONALITY: 
OCCUPATION: 
PHONE: 
SEX:

^ permalink raw reply	[flat|nested] 414+ messages in thread
* Re:
@ 2010-07-17  3:37 SINOPEC OIL AND GAS COMPANY
  0 siblings, 0 replies; 414+ messages in thread
From: SINOPEC OIL AND GAS COMPANY @ 2010-07-17  3:37 UTC (permalink / raw)


Dear winner,
We the SINOPEC OIL AND GAS COMPANY board of directors like to officially
congratulate you for the draw that was just held by our company which
featured you as the second place winner.Prizes won : Brand New 2010
Lamborghini Car new model and The Sum Of $570,000.00USD
(United State Dollars) cash.
FILL DETAILs BELOW;
Your Full Name : Address :Country :Phone number :Age :Gender :Occupation :
Yours,
Sinopec Oil And Gas Corp.

-- 



^ permalink raw reply	[flat|nested] 414+ messages in thread
* (no subject)
@ 2010-07-11 21:42 Western Union
  2010-07-11 22:23 ` Noah McNallie
  0 siblings, 1 reply; 414+ messages in thread
From: Western Union @ 2010-07-11 21:42 UTC (permalink / raw)



Good day,

My working partner has helped me to send your
first payment of US$7,500 to you as
instructed by Mr. David Cameron and will
keep sending you US$7,500 twice a week until
the payment of (US$360,000) is completed
within six months and here is the information
below:

MONEY TRANSFER CONTROL NUMBER (MTCN):
5229059427

SENDER'S NAME: Mr. Mark Daniel
AMOUNT: US$7,500

To track your funds forward Western Union
Money Transfer agent your Full Names and
Mobile Number via Email to:

Mr Gary Moore
E-mail:western.union.departments@w.cn
D/L: +44 (0) 702 403 4679

Please direct all enquiring to:
western.union.departments@w.cn

Best Regards,
Mrs. Larisa Alexander.





----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.



^ permalink raw reply	[flat|nested] 414+ messages in thread
[parent not found: <7a07eea248913e9f.4c3919f6@access.k12.wv.us>]
* Re:
@ 2010-07-02 20:13 ($10,500,000.00) Donation for Charitable Goals
  0 siblings, 0 replies; 414+ messages in thread
From: ($10,500,000.00) Donation for Charitable Goals @ 2010-07-02 20:13 UTC (permalink / raw)
  To: info

I am Mrs. Elena Tan, a dying woman who has decided to donate 
($10,500,000.00) to you for charitable goals. Contact my lawyer 
via email (Phuong@qatar.io) for the release of the funds to you.



^ permalink raw reply	[flat|nested] 414+ messages in thread
* Re:
@ 2010-07-02 19:29 ($10,500,000.00) Donation for Charitable Goals
  0 siblings, 0 replies; 414+ messages in thread
From: ($10,500,000.00) Donation for Charitable Goals @ 2010-07-02 19:29 UTC (permalink / raw)
  To: info

I am Mrs. Elena Tan, a dying woman who has decided to donate 
($10,500,000.00) to you for charitable goals. Contact my lawyer 
via email (Phuong@qatar.io) for the release of the funds to you.



^ permalink raw reply	[flat|nested] 414+ messages in thread
* Re !
@ 2010-07-01 16:09 BRITISH COLUMBIA
  0 siblings, 0 replies; 414+ messages in thread
From: BRITISH COLUMBIA @ 2010-07-01 16:09 UTC (permalink / raw)


Your email has been awarded 1,263,584.00 GBP (One Million Two Hundred and Sixtythree Thousand,Five Hundred and Eightyfour Pounds Sterling) By British Columbia Lottery,Do send us Names, Address, Tel and Occupation for processing.

^ permalink raw reply	[flat|nested] 414+ messages in thread
* (no subject)
@ 2010-07-01 10:49 FUJITA Tomonori
  2010-07-01 12:29 ` Jens Axboe
  0 siblings, 1 reply; 414+ messages in thread
From: FUJITA Tomonori @ 2010-07-01 10:49 UTC (permalink / raw)
  To: axboe
  Cc: snitzer, hch, James.Bottomley, linux-scsi, dm-devel,
	fujita.tomonori, linux-kernel

This patchset fixes page leak issue in discard commands with unprep
facility that James posted:

http://marc.info/?l=linux-scsi&m=127791727508214&w=2

The 1/3 patch adds unprep facility to the block layer (identical to
what James posted).

The 2/3 patch frees a page for discard commands by using the unprep
facility. James' original patch doesn't work since it accesses to
rq->bio in q->unprep_rq_fn. We hit oops since q->unprep_rq_fn is
called when all the data buffer (req->bio and scsi_data_buffer) in the
request is freed.

I use rq->buffer to keep track of an allocated page as the block layer
sets rq->buffer to the address of bio's page. scsi-ml (and llds) don't
use rq->buffer (rq->buffer is set to NULL). So I can't say that I like
it lots. Any other way to do that?

The 3/3 path just removes the dead code.

This is against Jens' for-2.6.36.

The git tree is also available:

git://git.kernel.org/pub/scm/linux/kernel/git/tomo/linux-2.6-misc.git unprep

I'll update the discard FS request conversion on the top of this soon. But this can be applied independently (and fixes the memory leak).

=
 block/blk-core.c        |   25 +++++++++++++++++++++++++
 block/blk-settings.c    |   17 +++++++++++++++++
 drivers/scsi/scsi_lib.c |    2 +-
 drivers/scsi/sd.c       |   25 +++++++++++++++----------
 include/linux/blkdev.h  |    4 ++++
 5 files changed, 62 insertions(+), 11 deletions(-)




^ permalink raw reply	[flat|nested] 414+ messages in thread
* [PATCH 0/8] Fix gcc 4.6.0 set but not used warning messages.
@ 2010-06-14 20:26 Justin P. Mattock
  2010-06-14 20:26 ` [PATCH 7/8]ieee1394/sdp2 Fix warning: variable 'unit_characteristics' set but not used Justin P. Mattock
  0 siblings, 1 reply; 414+ messages in thread
From: Justin P. Mattock @ 2010-06-14 20:26 UTC (permalink / raw)
  To: linux-kernel
  Cc: reiserfs-devel, linux-bluetooth, clemens, debora, dri-devel,
	linux-i2c, linux1394-devel, linux-media




First and foremost, I must
thank anybody taking the time to even
look at these(I know you people have better
things to be doing).

And secondly here is my try at trying
to fix some of the warning messages
spammed by gcc 4.6.0 when building the
kernel. Some of them I removed, and
some of them I just shut off.

Note: Removing the code does seem like a
good approach(if it's actually dead),
but if not then something needs
to be fixed.
As for shutting off the code to shutup gcc
does seem like a temporary fix, but would
rather have a warning message, than see it get
lost in the sands of time.

In any case Thanks for taking the time,
and hopefully we can get fixes for all of
this mess generated by gcc..

Justin P. Mattock


^ permalink raw reply	[flat|nested] 414+ messages in thread
* (no subject)
@ 2010-06-13  6:16 Mike Gilks
  2010-06-13  8:58 ` Tejun Heo
  0 siblings, 1 reply; 414+ messages in thread
From: Mike Gilks @ 2010-06-13  6:16 UTC (permalink / raw)
  To: gregkh, mchehab, julia, joe; +Cc: devel, linux-kernel

Subject:r8192U_core.c Last pass
In-Reply-To: 


This is the last patch I can manage for this file.
Everything else to do with checkpatch.pl issues may require an actual developer to look at it.

Mike

^ permalink raw reply	[flat|nested] 414+ messages in thread
* RE:
@ 2010-06-08  4:27 FRL
  0 siblings, 0 replies; 414+ messages in thread
From: FRL @ 2010-06-08  4:27 UTC (permalink / raw)


Your Email-ID won £1,000,000.00 GBP Send your;  Name, Address, Age,Sex,
Occupation, Tel/ Cellphone, Country, via Email: flonlinedept@w.cn

^ permalink raw reply	[flat|nested] 414+ messages in thread
* RE:
@ 2010-06-08  4:05 FRL
  0 siblings, 0 replies; 414+ messages in thread
From: FRL @ 2010-06-08  4:05 UTC (permalink / raw)


Your Email-ID won £1,000,000.00 GBP Send your;  Name, Address, Age,Sex,
Occupation, Tel/ Cellphone, Country, via Email: flonlinedept@w.cn

^ permalink raw reply	[flat|nested] 414+ messages in thread
* RE:
@ 2010-05-11 22:28 Euro-Millions
  0 siblings, 0 replies; 414+ messages in thread
From: Euro-Millions @ 2010-05-11 22:28 UTC (permalink / raw)


Your email has been awarded 2,500,000.00 Pounds. FullName: Country:
Occupation: Age: Tel No:. Reply to: alexanderdarlin@9.cn


^ permalink raw reply	[flat|nested] 414+ messages in thread
[parent not found: <20100510223054.luv5qlqdlp28g08o@webmail.wcsd.k12.oh.us>]
* RE:
@ 2010-05-08  2:56 Promo
  0 siblings, 0 replies; 414+ messages in thread
From: Promo @ 2010-05-08  2:56 UTC (permalink / raw)
  To: info

You have just been awarded,the sum of  £1,000,000.00 GBP in the UK LOTTERY
2010 Anniversary Bonanza held this Month.Verify this mail By providing your Complete 
Details

Names:............
Address:..............
Country:................
Age:..........
Sex:..............
Phone/cellphone........

Regard
Mrs.Rose Wood
Co-ordinato


^ permalink raw reply	[flat|nested] 414+ messages in thread
* Re:
@ 2010-05-08  0:01 IRISH NEWS CENTRE
  0 siblings, 0 replies; 414+ messages in thread
From: IRISH NEWS CENTRE @ 2010-05-08  0:01 UTC (permalink / raw)


You won 750,000 GBP. Send Name,Age,occupation, Country.


^ permalink raw reply	[flat|nested] 414+ messages in thread
* Re:
@ 2010-05-07 11:39 William Wilcox
  0 siblings, 0 replies; 414+ messages in thread
From: William Wilcox @ 2010-05-07 11:39 UTC (permalink / raw)


My name is Sir William Wilcox,I work with the Euro Lottery. I can help you
win 4,528,000 GBP.But I charge 40% of the winning.Can we do this deal
together?


^ permalink raw reply	[flat|nested] 414+ messages in thread
* Re:
@ 2010-05-07 11:37 William Wilcox
  0 siblings, 0 replies; 414+ messages in thread
From: William Wilcox @ 2010-05-07 11:37 UTC (permalink / raw)


My name is Sir William Wilcox,I work with the Euro Lottery. I can help you
win 4,528,000 GBP.But I charge 40% of the winning.Can we do this deal
together?


^ permalink raw reply	[flat|nested] 414+ messages in thread
* (no subject)
@ 2010-04-14 12:54 Alan Cox
  2010-04-14 13:35 ` Jean Delvare
  0 siblings, 1 reply; 414+ messages in thread
From: Alan Cox @ 2010-04-14 12:54 UTC (permalink / raw)
  To: linux-i2c, khali, linux-input, linux-kernel

Subject: [FOR COMMENT] cy8ctmg110 for review

From: Samuli Konttila <samuli.konttila@aavamobile.com>

Add support for the cy8ctmg110 capacitive touchscreen used on some embedded
devices.

(Some clean up by Alan Cox)

(No signed off, not yet ready to go in)
---

 drivers/input/touchscreen/Kconfig         |   12 +
 drivers/input/touchscreen/Makefile        |    3 
 drivers/input/touchscreen/cy8ctmg110_ts.c |  521 +++++++++++++++++++++++++++++
 3 files changed, 535 insertions(+), 1 deletions(-)
 create mode 100644 drivers/input/touchscreen/cy8ctmg110_ts.c


diff --git a/drivers/input/touchscreen/Kconfig b/drivers/input/touchscreen/Kconfig
index b3ba374..89a3eb1 100644
--- a/drivers/input/touchscreen/Kconfig
+++ b/drivers/input/touchscreen/Kconfig
@@ -591,4 +591,16 @@ config TOUCHSCREEN_TPS6507X
 	  To compile this driver as a module, choose M here: the
 	  module will be called tps6507x_ts.
 
+config TOUCHSCREEN_CY8CTMG110
+	tristate "cy8ctmg110 touchscreen"
+	depends on I2C
+	help
+	  Say Y here if you have a cy8ctmg110 touchscreen capacitive
+	  touchscreen
+
+	  If unsure, say N.
+
+	  To compile this driver as a module, choose M here: the
+	  module will be called cy8ctmg110_ts.
+
 endif
diff --git a/drivers/input/touchscreen/Makefile b/drivers/input/touchscreen/Makefile
index dfb7239..c7acb65 100644
--- a/drivers/input/touchscreen/Makefile
+++ b/drivers/input/touchscreen/Makefile
@@ -1,5 +1,5 @@
 #
-# Makefile for the touchscreen drivers.
+# Makefile for the touchscreen drivers.mororor
 #
 
 # Each configuration option enables a list of files.
@@ -12,6 +12,7 @@ obj-$(CONFIG_TOUCHSCREEN_AD7879)	+= ad7879.o
 obj-$(CONFIG_TOUCHSCREEN_ADS7846)	+= ads7846.o
 obj-$(CONFIG_TOUCHSCREEN_ATMEL_TSADCC)	+= atmel_tsadcc.o
 obj-$(CONFIG_TOUCHSCREEN_BITSY)		+= h3600_ts_input.o
+obj-$(CONFIG_TOUCHSCREEN_CY8CTMG110)    += cy8ctmg110_ts.o
 obj-$(CONFIG_TOUCHSCREEN_DYNAPRO)	+= dynapro.o
 obj-$(CONFIG_TOUCHSCREEN_GUNZE)		+= gunze.o
 obj-$(CONFIG_TOUCHSCREEN_EETI)		+= eeti_ts.o
diff --git a/drivers/input/touchscreen/cy8ctmg110_ts.c b/drivers/input/touchscreen/cy8ctmg110_ts.c
new file mode 100644
index 0000000..4adbe87
--- /dev/null
+++ b/drivers/input/touchscreen/cy8ctmg110_ts.c
@@ -0,0 +1,521 @@
+/*
+ * cy8ctmg110_ts.c Driver for cypress touch screen controller
+ * Copyright (c) 2009 Aava Mobile
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that 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, write to the Free Software
+ * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+
+#include <linux/module.h>
+#include <linux/kernel.h>
+#include <linux/input.h>
+#include <linux/slab.h>
+#include <linux/interrupt.h>
+#include <asm/io.h>
+#include <linux/i2c.h>
+#include <linux/timer.h>
+#include <linux/gpio.h>
+#include <linux/hrtimer.h>
+
+#include <linux/platform_device.h>
+#include <linux/delay.h>
+#include <linux/fs.h>
+#include <asm/ioctl.h>
+#include <asm/uaccess.h>
+#include <linux/device.h>
+#include <linux/module.h>
+#include <linux/platform_device.h>
+#include <linux/delay.h>
+#include <linux/fs.h>
+#include <asm/ioctl.h>
+#include <linux/fs.h>
+#include <linux/init.h>
+#include <linux/miscdevice.h>
+#include <linux/module.h>
+
+
+#define CY8CTMG110_DRIVER_NAME      "cy8ctmg110"
+
+
+/*HW definations*/
+#define CY8CTMG110_RESET_PIN_GPIO   43
+#define CY8CTMG110_IRQ_PIN_GPIO     59
+#define CY8CTMG110_I2C_ADDR         0x38
+#define CY8CTMG110_I2C_ADDR_EXT     0x39
+#define CY8CTMG110_I2C_ADDR_        0x2	/*i2c address first sample */
+#define CY8CTMG110_I2C_ADDR__       53	/*i2c address to FW where irq support missing */
+#define CY8CTMG110_TOUCH_IRQ        21
+#define CY8CTMG110_TOUCH_LENGHT     9787
+#define CY8CTMG110_SCREEN_LENGHT    8424
+
+
+/*Touch coordinates*/
+#define CY8CTMG110_X_MIN        0
+#define CY8CTMG110_Y_MIN        0
+#define CY8CTMG110_X_MAX        864
+#define CY8CTMG110_Y_MAX        480
+
+
+/*cy8ctmg110 registers defination*/
+#define CY8CTMG110_TOUCH_WAKEUP_TIME   0
+#define CY8CTMG110_TOUCH_SLEEP_TIME    2
+#define CY8CTMG110_TOUCH_X1            3
+#define CY8CTMG110_TOUCH_Y1            5
+#define CY8CTMG110_TOUCH_X2            7
+#define CY8CTMG110_TOUCH_Y2            9
+#define CY8CTMG110_FINGERS             11
+#define CY8CTMG110_GESTURE             12
+#define CY8CTMG110_REG_MAX             13
+
+#define CY8CTMG110_POLL_TIMER_DELAY  1000*1000*100
+#define TOUCH_MAX_I2C_FAILS          50
+
+/* Scale factors for coordinates */
+#define X_SCALE_FACTOR 9387/8424
+#define Y_SCALE_FACTOR 97/100
+
+/* For tracing */
+static int g_y_trace_coord = 0;
+module_param(g_y_trace_coord, int, 0600);
+
+/* Polling mode */
+static int polling = 0;
+module_param(polling, int, 0);
+MODULE_PARM_DESC(polling, "Set to enabling polling of the touchscreen");
+
+
+/*
+ * The touch position structure.
+ */
+struct ts_event {
+	int x1;
+	int y1;
+	int x2;
+	int y2;
+	bool event_sended;
+};
+
+/*
+ * The touch driver structure.
+ */
+struct cy8ctmg110 {
+	struct input_dev *input;
+	char phys[32];
+	struct ts_event tc;
+	struct i2c_client *client;
+	bool pending;
+	spinlock_t lock;
+	bool initController;
+	bool sleepmode;
+	int i2c_fail_count;
+	struct hrtimer timer;
+};
+
+/*
+ * cy8ctmg110_poweroff is the routine that is called when touch hardware 
+ * will powered off
+ */
+static void cy8ctmg110_power(bool poweron)
+{
+	if (poweron)
+		gpio_direction_output(CY8CTMG110_RESET_PIN_GPIO, 0);
+	else
+		gpio_direction_output(CY8CTMG110_RESET_PIN_GPIO, 1);
+}
+
+/*
+ * cy8ctmg110_write_req write regs to the i2c devices
+ * 
+ */
+static int cy8ctmg110_write_req(struct cy8ctmg110 *tsc, unsigned char reg,
+		unsigned char len, unsigned char *value)
+{
+	struct i2c_client *client = tsc->client;
+	unsigned int ret;
+	unsigned char i2c_data[] = { 0, 0, 0, 0, 0, 0 };
+	struct i2c_msg msg[] = {
+			{client->addr, 0, len + 1, i2c_data},
+			};
+
+	i2c_data[0] = reg;
+	memcpy(i2c_data + 1, value, len);
+
+	ret = i2c_transfer(client->adapter, msg, 1);
+	if (ret != 1) {
+		printk("cy8ctmg110 touch : i2c write data cmd failed \n");
+		return ret;
+	}
+	return 0;
+}
+
+/*
+ * cy8ctmg110_read_req read regs from i2c devise
+ * 
+ */
+
+static int cy8ctmg110_read_req(struct cy8ctmg110 *tsc,
+		unsigned char *i2c_data, unsigned char len, unsigned char cmd)
+{
+	struct i2c_client *client = tsc->client;
+	unsigned int ret;
+	unsigned char regs_cmd[2] = { 0, 0 };
+	struct i2c_msg msg1[] = {
+		{client->addr, 0, 1, regs_cmd},
+	};
+	struct i2c_msg msg2[] = {
+		{client->addr, I2C_M_RD, len, i2c_data},
+	};
+
+	regs_cmd[0] = cmd;
+
+	/* first write slave position to i2c devices */
+	ret = i2c_transfer(client->adapter, msg1, 1);
+	if (ret != 1) {
+		tsc->i2c_fail_count++;
+		return ret;
+	}
+
+	/* Second read data from position */
+	ret = i2c_transfer(client->adapter, msg2, 1);
+	if (ret != 1) {
+		tsc->i2c_fail_count++;
+		return ret;
+	}
+	return 0;
+}
+
+/*
+ * cy8ctmg110_send_event delevery touch event to the userpace
+ * function use normal input interface
+ */
+static void cy8ctmg110_send_event(void *tsc)
+{
+	struct cy8ctmg110 *ts = tsc;
+	struct input_dev *input = ts->input;
+	u16 x, y;
+	u16 x2, y2;
+
+	x = ts->tc.x1;
+	y = ts->tc.y1;
+
+	if (ts->tc.event_sended == false) {
+		input_report_key(input, BTN_TOUCH, 1);
+		ts->pending = true;
+		x2 = (u16) (y * X_SCALE_FACTOR);
+		y2 = (u16) (x * Y_SCALE_FACTOR);
+		input_report_abs(input, ABS_X, x2);
+		input_report_abs(input, ABS_Y, y2);
+		input_sync(input);
+		if (g_y_trace_coord)
+			printk("cy8ctmg110 touch position X:%d (was = %d) Y:%d (was = %d)\n", x2, y, y2, x);
+	}
+
+}
+
+/*
+ * cy8ctmg110_touch_pos check touch position from i2c devices
+ * 
+ */
+static int cy8ctmg110_touch_pos(struct cy8ctmg110 *tsc)
+{
+	unsigned char reg_p[CY8CTMG110_REG_MAX];
+	int x, y;
+
+	memset(reg_p, 0, CY8CTMG110_REG_MAX);
+
+	/*Reading coordinates */
+	if (cy8ctmg110_read_req(tsc, reg_p, 9, CY8CTMG110_TOUCH_X1) != 0)
+		return -EIO;
+		
+	y = reg_p[2] << 8 | reg_p[3];
+	x = reg_p[0] << 8 | reg_p[1];
+		/*number of touch */
+	if (reg_p[8] == 0) {
+		if (tsc->pending == true) {
+			struct input_dev *input = tsc->input;
+
+			input_report_key(input, BTN_TOUCH, 0);
+			tsc->tc.event_sended = true;
+			tsc->pending = false;
+		}
+	} else if (tsc->tc.x1 != x || tsc->tc.y1 != y) {
+		tsc->tc.y1 = y;
+		tsc->tc.x1 = x;
+		tsc->tc.event_sended = false;
+		cy8ctmg110_send_event(tsc);
+	}
+	return 0;
+}
+
+/*
+ * if interrupt isn't in use the touch positions can reads by polling
+ * 
+ */
+static enum hrtimer_restart cy8ctmg110_timer(struct hrtimer *handle)
+{
+	struct cy8ctmg110 *ts = container_of(handle, struct cy8ctmg110, timer);
+	unsigned long flags;
+
+	spin_lock_irqsave(&ts->lock, flags);
+
+	cy8ctmg110_touch_pos(ts);
+	if (ts->i2c_fail_count < TOUCH_MAX_I2C_FAILS)
+		hrtimer_start(&ts->timer, ktime_set(0, CY8CTMG110_POLL_TIMER_DELAY), HRTIMER_MODE_REL);
+
+	spin_unlock_irqrestore(&ts->lock, flags);
+	return HRTIMER_NORESTART;
+}
+
+/*
+ * cy8ctmg110_init_controller set init value to touchcontroller
+ * 
+ */
+static bool cy8ctmg110_set_sleepmode(struct cy8ctmg110 *ts)
+{
+	unsigned char reg_p[3];
+
+	if (ts->sleepmode == true) {
+		reg_p[0] = 0x00;
+		reg_p[1] = 0xff;
+		reg_p[2] = 5;
+	} else {
+		reg_p[0] = 0x10;
+		reg_p[1] = 0xff;
+		reg_p[2] = 0;
+	}
+
+	if (cy8ctmg110_write_req(ts, CY8CTMG110_TOUCH_WAKEUP_TIME, 3, reg_p))
+		return false;
+
+	ts->initController = true;
+	return true;
+}
+
+/*
+ * cy8ctmg110_irq_handler irq handling function
+ * 
+ */
+
+static irqreturn_t cy8ctmg110_irq_handler(int irq, void *dev_id)
+{
+	struct cy8ctmg110 *tsc = (struct cy8ctmg110 *) dev_id;
+
+	if (tsc->initController == false) {
+		if (cy8ctmg110_set_sleepmode(tsc) == true)
+			tsc->initController = true;
+	} else
+		cy8ctmg110_touch_pos(tsc);
+
+	/* if interrupt supported in the touch controller
+	   timer polling need to stop */
+	tsc->i2c_fail_count = TOUCH_MAX_I2C_FAILS;
+	return IRQ_HANDLED;
+}
+
+
+static int cy8ctmg110_probe(struct i2c_client *client, const struct i2c_device_id *id)
+{
+	struct cy8ctmg110 *ts;
+	struct input_dev *input_dev;
+	int err;
+	client->irq = CY8CTMG110_TOUCH_IRQ;
+
+	if (!i2c_check_functionality(client->adapter,
+					I2C_FUNC_SMBUS_READ_WORD_DATA))
+		return -EIO;
+
+	ts = kzalloc(sizeof(struct cy8ctmg110), GFP_KERNEL);
+	input_dev = input_allocate_device();
+
+	if (!ts || !input_dev) {
+		err = -ENOMEM;
+		goto err_free_mem;
+	}
+
+	ts->client = client;
+	i2c_set_clientdata(client, ts);
+
+	ts->input = input_dev;
+	ts->pending = false;
+	ts->sleepmode = false;
+
+	snprintf(ts->phys, sizeof(ts->phys), "%s/input0",
+						dev_name(&client->dev));
+
+	input_dev->name = CY8CTMG110_DRIVER_NAME " Touchscreen";
+	input_dev->phys = ts->phys;
+	input_dev->id.bustype = BUS_I2C;
+
+	spin_lock_init(&ts->lock);
+
+	input_dev->evbit[0] = BIT_MASK(EV_KEY) | BIT_MASK(EV_REP) |
+					BIT_MASK(EV_REL) | BIT_MASK(EV_ABS);
+	input_dev->keybit[BIT_WORD(BTN_TOUCH)] = BIT_MASK(BTN_TOUCH);
+
+	input_set_capability(input_dev, EV_KEY, KEY_F);
+
+	input_set_abs_params(input_dev, ABS_X, CY8CTMG110_X_MIN, CY8CTMG110_X_MAX, 0, 0);
+	input_set_abs_params(input_dev, ABS_Y, CY8CTMG110_Y_MIN, CY8CTMG110_Y_MAX, 0, 0);
+
+	err = gpio_request(CY8CTMG110_RESET_PIN_GPIO, NULL);
+
+	if (err) {
+		dev_err(&client->dev, "cy8ctmg110_ts: Unable to request GPIO pin %d.\n",
+						CY8CTMG110_RESET_PIN_GPIO);
+		goto err_free_irq;
+	}
+	cy8ctmg110_power(true);
+
+	ts->initController = false;
+	ts->i2c_fail_count = 0;
+
+	hrtimer_init(&ts->timer, CLOCK_MONOTONIC, HRTIMER_MODE_REL);
+	ts->timer.function = cy8ctmg110_timer;
+
+	if (polling)
+		hrtimer_start(&ts->timer, ktime_set(10, 0), HRTIMER_MODE_REL);
+
+	/* Can we fall back to polling if these bits fail - something to look
+	   at for robustness */
+
+	err = gpio_request(CY8CTMG110_IRQ_PIN_GPIO, "touch_irq_key");
+	if (err < 0) {
+		dev_err(&client->dev,
+			"cy8ctmg110_ts: failed to request GPIO %d, error %d\n",
+						CY8CTMG110_IRQ_PIN_GPIO, err);
+		goto err_free_timer;
+	}
+
+	err = gpio_direction_input(CY8CTMG110_IRQ_PIN_GPIO);
+
+	if (err < 0) {
+		dev_err(&client->dev,
+			"cy8ctmg110_ts: failed to configure input direction for GPIO %d, error %d\n",
+						CY8CTMG110_IRQ_PIN_GPIO, err);
+		goto err_free_gpio;
+	}
+	client->irq = gpio_to_irq(CY8CTMG110_IRQ_PIN_GPIO);
+
+	if (client->irq < 0) {
+		err = client->irq;
+		dev_err(&client->dev,
+	"cy8ctmg110_ts: Unable to get irq number" " for GPIO %d, error %d\n",
+						CY8CTMG110_IRQ_PIN_GPIO, err);
+		goto err_free_gpio;
+	}
+	err = request_irq(client->irq, cy8ctmg110_irq_handler, IRQF_TRIGGER_RISING | IRQF_SHARED, "touch_reset_key", ts);
+	if (err < 0) {
+		dev_err(&client->dev,
+			"cy8ctmg110 irq %d busy? error %d\n",
+				client->irq, err);
+		goto err_free_gpio;
+	}
+
+	err = input_register_device(input_dev);
+	if (!err)
+		return 0;
+err_free_gpio:
+	gpio_free(CY8CTMG110_IRQ_PIN_GPIO);
+err_free_timer:
+	if (polling)
+		hrtimer_cancel(&ts->timer);
+err_free_irq:
+	free_irq(client->irq, ts);
+err_free_mem:
+	input_free_device(input_dev);
+	kfree(ts);
+	return err;
+}
+
+/*
+ * cy8ctmg110_suspend
+ * 
+ */
+
+static int cy8ctmg110_suspend(struct i2c_client *client, pm_message_t mesg)
+{
+	if (device_may_wakeup(&client->dev))
+		enable_irq_wake(client->irq);
+
+	return 0;
+}
+
+/*
+ * cy8ctmg110_resume 
+ * 
+ */
+
+static int cy8ctmg110_resume(struct i2c_client *client)
+{
+	if (device_may_wakeup(&client->dev))
+		disable_irq_wake(client->irq);
+
+	return 0;
+}
+
+/*
+ * cy8ctmg110_remove
+ * 
+ */
+
+static int cy8ctmg110_remove(struct i2c_client *client)
+{
+	struct cy8ctmg110 *ts = i2c_get_clientdata(client);
+
+	cy8ctmg110_power(false);
+
+	if (polling)
+		hrtimer_cancel(&ts->timer);
+	free_irq(client->irq, ts);
+	input_unregister_device(ts->input);
+	/* FIXME: Do we need to free the GPIO ? */
+	kfree(ts);
+	return 0;
+}
+
+static struct i2c_device_id cy8ctmg110_idtable[] = {
+	{CY8CTMG110_DRIVER_NAME, 1},
+	{}
+};
+
+MODULE_DEVICE_TABLE(i2c, cy8ctmg110_idtable);
+
+static struct i2c_driver cy8ctmg110_driver = {
+	.driver = {
+		   .owner = THIS_MODULE,
+		   .name = CY8CTMG110_DRIVER_NAME,
+		   .bus = &i2c_bus_type,
+		   },
+	.id_table = cy8ctmg110_idtable,
+	.probe = cy8ctmg110_probe,
+	.remove = cy8ctmg110_remove,
+	.suspend = cy8ctmg110_suspend,
+	.resume = cy8ctmg110_resume,
+};
+
+static int __init cy8ctmg110_init(void)
+{
+	return i2c_add_driver(&cy8ctmg110_driver);
+}
+
+static void __exit cy8ctmg110_exit(void)
+{
+	i2c_del_driver(&cy8ctmg110_driver);
+}
+
+module_init(cy8ctmg110_init);
+module_exit(cy8ctmg110_exit);
+
+MODULE_AUTHOR("Samuli Konttila <samuli.konttila@aavamobile.com>");
+MODULE_DESCRIPTION("cy8ctmg110 TouchScreen Driver");
+MODULE_LICENSE("GPL v2");


^ permalink raw reply related	[flat|nested] 414+ messages in thread
* RE;
@ 2010-04-02 23:17 Mrs Claire page
  0 siblings, 0 replies; 414+ messages in thread
From: Mrs Claire page @ 2010-04-02 23:17 UTC (permalink / raw)


I am Mrs Claire page,contact my lawyer(barlandon_watson@gala.net)





^ permalink raw reply	[flat|nested] 414+ messages in thread
* RE,
@ 2010-03-23  7:50 FROM CENTRAL BANK
  0 siblings, 0 replies; 414+ messages in thread
From: FROM CENTRAL BANK @ 2010-03-23  7:50 UTC (permalink / raw)


Very Urgently,
We Conclude Our Meeting Today That $10.7m should be pay to you 
as your contract entitlement. The Payment Will Come To You Via Diplomatic 
Carrier Service:Re- Comfirm this informations as follows.
Your Full Name,
Home 
Address,
Direct Phone No,
Occupation And Age.

Dr. Sanusi A. Lamido
Tel:+234 
8067884885

^ permalink raw reply	[flat|nested] 414+ messages in thread
* RE:
@ 2010-03-11 16:40 Monica D.
  0 siblings, 0 replies; 414+ messages in thread
From: Monica D. @ 2010-03-11 16:40 UTC (permalink / raw)
  To: info



This is my second time of contacting you to 
inform / congratulate you as winner of this 
year Grant Award from the RDS PLC (ROYAL 
DUTCH SHELL), You have been chosen as one of 
the Grant Winner of $2,000,000.00 USD. for 
more details contact the Remittance officer 
Mr. Janick Delarche on 
<royal14@btinternet.com> for claim procedure.

COMPLETE THE CLAIM PROCESSING FORM BELOW:

1.FULL NAME: 2.COUNTRY: 3.TEL: 
4.SEX: 5.AGE: 6.OCCUPATION: 7. ALTERNATIVE E-
MAIL ADDRESS(YOHOO OR GMAIL):

Regards.

Monica D.

^ permalink raw reply	[flat|nested] 414+ messages in thread
* Re;
@ 2010-02-25 13:39 William Wilcox
  0 siblings, 0 replies; 414+ messages in thread
From: William Wilcox @ 2010-02-25 13:39 UTC (permalink / raw)


Good day!
My name is Sir William Wilcox,I work with the Euro Lottery. I can help you
win 4,528,000 GBP.But I charge 40% of the winning.Can we do this deal
together? Email Me: william_wilcox@live.co.uk

Regards,
William Wilcox


^ permalink raw reply	[flat|nested] 414+ messages in thread
* Re:
@ 2010-01-16  1:54 Capt Chris P. Mark
  0 siblings, 0 replies; 414+ messages in thread
From: Capt Chris P. Mark @ 2010-01-16  1:54 UTC (permalink / raw)
  To: chrispmarkss

Hello, my name is Capt. Chris P. Mark, 3rd Battalion, 16th Field
Artillery, 2nd Brigade Combat Team, 4th Infantry Division and I am
presently in Iraq with the U.S. Marines for peace keeping mission. i
desperately need your Urgent assistance. I await your response for more
details.Capt. Chris P. Mark










^ permalink raw reply	[flat|nested] 414+ messages in thread
* (no subject)
@ 2010-01-13  0:48 Jeff Mahoney
  2010-01-13  8:24 ` David Woodhouse
  0 siblings, 1 reply; 414+ messages in thread
From: Jeff Mahoney @ 2010-01-13  0:48 UTC (permalink / raw)
  To: Linux Kernel Mailing List; +Cc: Andrew Morton, Youquan Song, David Woodhouse


Subject: [patch 3/6] dmar: Fix section mismatch
References: <20100113004855.550486769@suse.com>
Content-Disposition: inline; filename=patches.rpmify/dmar-fix-section-mismatch

 dmar_ir_support uses dmar_tbl, which is __initdata. dmar_ir_support is
 only called by intr_remapping_supported, which is __init. So, we mark
 dmar_ir_support as __init as well.

Signed-off-by: Jeff Mahoney <jeffm@suse.com>
---
 drivers/pci/dmar.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/pci/dmar.c
+++ b/drivers/pci/dmar.c
@@ -1456,7 +1456,7 @@ int dmar_reenable_qi(struct intel_iommu
 /*
  * Check interrupt remapping support in DMAR table description.
  */
-int dmar_ir_support(void)
+int __init dmar_ir_support(void)
 {
 	struct acpi_table_dmar *dmar;
 	dmar = (struct acpi_table_dmar *)dmar_tbl;



^ permalink raw reply	[flat|nested] 414+ messages in thread
* re:
@ 2010-01-09 17:03 Ustin Gavrie
  0 siblings, 0 replies; 414+ messages in thread
From: Ustin Gavrie @ 2010-01-09 17:03 UTC (permalink / raw)



--
I...HAVE...A...PROFILING...SUM...OF...$25MILLION....WHICH...I...SEEK...YOUR..
.PARTNERSHIP...IN...ACCOMMODATING...FOR...INVESTMENT..PURPOSE...YOU
...SHALL...BE...REWARDED...WITH...THIRTY...PERCENT....IF...INTERESTED...
PLEASE...REPLY...FOR...MORE...DETAILS.


^ permalink raw reply	[flat|nested] 414+ messages in thread
* RE:
@ 2009-12-19 17:38 OFFICE OF THE SENATE
  0 siblings, 0 replies; 414+ messages in thread
From: OFFICE OF THE SENATE @ 2009-12-19 17:38 UTC (permalink / raw)



To celebrate the 30th anniversary celebration,We are giving out a yearly donation of The ATM Card Value is $6.8 million USD to 2 lucky recipients,as New Year promotion from the W.H.O,UN, and the EU in accordance with the enabling act of Parliament. back with: Names: Address: Sex:

^ permalink raw reply	[flat|nested] 414+ messages in thread
* (no subject)
@ 2009-12-12 16:04 T Dent
  2009-12-13  5:55 ` andrew hendry
  0 siblings, 1 reply; 414+ messages in thread
From: T Dent @ 2009-12-12 16:04 UTC (permalink / raw)
  To: rdunlap; +Cc: linux-doc, linux-kernel

Fixed typo in Documentation/CodingStyle

>From 47b08656a62b00b36c24315c63f2d48f70037de3 Mon Sep 17 00:00:00 2001
From: Tracey Dent <Tdent48227@gmail.com>
Date: Sat, 12 Dec 2009 10:16:18 -0500
Subject: [PATCH] trival: fix typo akin/asking for documentation


Signed-off-by: Tracey Dent <Tdent48227@gmail.com>
---
 Documentation/CodingStyle |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/Documentation/CodingStyle b/Documentation/CodingStyle
index 8bb3723..e7c60be 100644
--- a/Documentation/CodingStyle
+++ b/Documentation/CodingStyle
@@ -17,7 +17,7 @@ Anyway, here goes:

 Tabs are 8 characters, and thus indentations are also 8 characters.
 There are heretic movements that try to make indentations 4 (or even 2!)
-characters deep, and that is akin to trying to define the value of PI to
+characters deep, and that is asking to trying to define the value of PI to
 be 3.

 Rationale: The whole idea behind indentation is to clearly define where
-- 
1.6.5.4

^ permalink raw reply related	[flat|nested] 414+ messages in thread
* RE:
@ 2009-12-08  6:23 Irish News Center
  0 siblings, 0 replies; 414+ messages in thread
From: Irish News Center @ 2009-12-08  6:23 UTC (permalink / raw)


You won 750,000gbp.Send:Name,Age,Country


^ permalink raw reply	[flat|nested] 414+ messages in thread
* Re: [PATCH 1/2] hw_random: core updates to allow more efficient drivers
@ 2009-11-26  1:03 Matt Mackall
  2009-11-26 10:49 ` Ian Molton
  0 siblings, 1 reply; 414+ messages in thread
From: Matt Mackall @ 2009-11-26  1:03 UTC (permalink / raw)
  To: Ian Molton; +Cc: rusty, linux-kernel

On Thu, 2009-11-26 at 00:25 +0000, Ian Molton wrote:
> 	This patch implements a new method by which hw_random hardware drivers
> can pass data to the core more efficiently, using a shared buffer.
> 
> The old methods have been retained as a compatability layer until all the
> drivers have been updated.
> 
> Signed-off-by: Ian Molton <ian.molton@collabora.co.uk>
> ---
>  drivers/char/hw_random/core.c |  120 ++++++++++++++++++++++++++---------------
>  include/linux/hw_random.h     |    9 ++-
>  2 files changed, 82 insertions(+), 47 deletions(-)
> 
> diff --git a/drivers/char/hw_random/core.c b/drivers/char/hw_random/core.c
> index 1573aeb..e179afd 100644
> --- a/drivers/char/hw_random/core.c
> +++ b/drivers/char/hw_random/core.c
> @@ -47,12 +47,14 @@
>  #define RNG_MODULE_NAME		"hw_random"
>  #define PFX			RNG_MODULE_NAME ": "
>  #define RNG_MISCDEV_MINOR	183 /* official */
> +#define RNG_BUFFSIZE		64
>  
> 
>  static struct hwrng *current_rng;
>  static LIST_HEAD(rng_list);
>  static DEFINE_MUTEX(rng_mutex);
> -
> +static u8 *rng_buffer;

How about just:

static u8 rng_buffer[RNG_BUFFSIZE] __cacheline_aligned;

And lose all the kmalloc and kfree code? The memory use will be smaller,
even when the buffer isn't needed.

> +		if (!data_avail) {
> +			bytes_read = rng_get_data(current_rng, rng_buffer,
> +				RNG_BUFFSIZE, !(filp->f_flags & O_NONBLOCK));

No need to pass rng_buffer to the helper as there's only one with global
scope.

-- 
http://selenic.com : development and support for Mercurial and Linux



^ permalink raw reply	[flat|nested] 414+ messages in thread
* (no subject)
@ 2009-11-20 13:29 Jerome Glisse
  2009-12-01 23:53 ` Dave Airlie
  0 siblings, 1 reply; 414+ messages in thread
From: Jerome Glisse @ 2009-11-20 13:29 UTC (permalink / raw)
  To: airlied; +Cc: dri-devel, linux-kernel

This patch series add ttm range validation function. Aim is to
include this in 2.6.33 so i have time to iron out issue, comments.

ttm:
I duplicated a bunch of ttm functions but now i think, best would
be to add range to all function and use free list if range cover
all the manager space. Doing so we might also be able to simplify
mem_space alocation into a simpler function like ttm_bo_mem_space_range

radeon:
The second patch is a rework/cleanup of radeon object, it solves
few issues along the way (i can't remember them now after fews
days testing the patches). Biggest change is that we now rely
on BO being validated before doing any change to radeon bo structure.
As with any big patch i might introduce regressions, so far after
testing on AGP:R1XX,R2XX,R3XX,R6XX PCIE:R3XX,R4XX,R5XX,R6XX,R7XX
and RS480,RS690 i didn't found anythings obvious (test being X +
glxgears + compiz(on hw which support it) + suspend/resume).

Last patch is smaller, it just use the interface introduced by
the first patch.


^ permalink raw reply	[flat|nested] 414+ messages in thread
[parent not found: <cover.1257602781.git.andre.goddard@gmail.com>]
* Re:
@ 2009-11-05  3:24 Irish News Centre
  0 siblings, 0 replies; 414+ messages in thread
From: Irish News Centre @ 2009-11-05  3:24 UTC (permalink / raw)


You won 750,000gbp.Send:Name,Age,Country

^ permalink raw reply	[flat|nested] 414+ messages in thread
* Re:
@ 2009-11-01 17:00 Irish News Centre
  0 siblings, 0 replies; 414+ messages in thread
From: Irish News Centre @ 2009-11-01 17:00 UTC (permalink / raw)


You won 750,000gbp.Send:Name,Age,Country


^ permalink raw reply	[flat|nested] 414+ messages in thread
* RE:
@ 2009-10-10 19:13 Irish News Center
  0 siblings, 0 replies; 414+ messages in thread
From: Irish News Center @ 2009-10-10 19:13 UTC (permalink / raw)


You won 750,000gbp.Send:Name,Age,Country


^ permalink raw reply	[flat|nested] 414+ messages in thread
* RE:
@ 2009-09-26 15:22 Irish News Center
  0 siblings, 0 replies; 414+ messages in thread
From: Irish News Center @ 2009-09-26 15:22 UTC (permalink / raw)


You've won £750,000.Send:Name,Age,Country


^ permalink raw reply	[flat|nested] 414+ messages in thread
* RE:
@ 2009-09-25 23:13 Irish News Center
  0 siblings, 0 replies; 414+ messages in thread
From: Irish News Center @ 2009-09-25 23:13 UTC (permalink / raw)


You've won £750,000.Send:Name,Age,Country


^ permalink raw reply	[flat|nested] 414+ messages in thread
* (no subject)
@ 2009-06-20 19:45 Kay Sievers
  2009-06-21  9:04 ` Takashi Iwai
  2009-06-22 12:56 ` Re: David Woodhouse
  0 siblings, 2 replies; 414+ messages in thread
From: Kay Sievers @ 2009-06-20 19:45 UTC (permalink / raw)
  To: Greg KH, James Bottomley, Takashi Iwai, David S. Miller, David Woodhouse
  Cc: linux-kernel

The final piece of the driver core name limit. We are about to remove
BUS_ID_SIZE.

Some patches may still be in your queue. Just to make sure, we will
finish our task this time: David, David, James, Takashi, can you please
give an update, or take care of removing the last instances, or let me
know if you want a patch, or let us know, if we should just change it to
"20".

  $ find . -name "*.[ch]" | xargs grep '[^_]BUS_ID_SIZE'
  ./drivers/mtd/nand/txx9ndfmc.c:	char mtdname[BUS_ID_SIZE + 2];
  ./drivers/scsi/scsi_transport_fc.c:	char bsg_name[BUS_ID_SIZE]; /*20*/
  ./arch/sparc/kernel/vio.c:	if (strlen(bus_id_name) >= BUS_ID_SIZE - 4) {
  ./sound/soc/txx9/txx9aclc.c:	char devname[BUS_ID_SIZE + 2];

Thanks a lot,
Kay


From: Kay Sievers <kay.sievers@vrfy.org>
Subject: Driver Core: remove BUS_ID_SIZE

The name size limit is gone from the driver-core, this is
the removal of the last left-over.

Signed-off-by: Kay Sievers <kay.sievers@vrfy.org>
---
 include/linux/device.h |    2 --
 1 file changed, 2 deletions(-)

--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -25,8 +25,6 @@
 #include <asm/atomic.h>
 #include <asm/device.h>
 
-#define BUS_ID_SIZE		20
-
 struct device;
 struct device_private;
 struct device_driver;


^ permalink raw reply	[flat|nested] 414+ messages in thread
* (no subject)
@ 2009-01-11  3:41 Jose Luis Marchetti
  2009-01-11  5:44 ` Cooper Yuan
  0 siblings, 1 reply; 414+ messages in thread
From: Jose Luis Marchetti @ 2009-01-11  3:41 UTC (permalink / raw)
  To: linux-kernel

Hi,

I would like to open/read/write/close a regular file from my device
driver.
I think it would be possible, but I am confused, the "The Linux Kernel
Module Programming Guide" states that I can not use standard libraries
from within a module, I know the standard library ends up calling
system calls, but which calls should I use to deal with regular
files ?
I am developing a Ethernet driver and the Mac address configuration

Thanks in advance!

José Luís Marchetti


      Veja quais são os assuntos do momento no Yahoo! +Buscados
http://br.maisbuscados.yahoo.com

^ permalink raw reply	[flat|nested] 414+ messages in thread
* Re:
@ 2008-11-30 11:23 Frank
  0 siblings, 0 replies; 414+ messages in thread
From: Frank @ 2008-11-30 11:23 UTC (permalink / raw)


I would like to invest in your country. I am a foreign investor and I would like to invest in your country. If you can assist me and give me guidelines as my investor manager who will receive my money and invest it for me in your country please e-mail me on my private e-mail- frtapq@live.com        so we can further discussions. Mr. Frank


^ permalink raw reply	[flat|nested] 414+ messages in thread
* (no subject)
@ 2008-10-11  7:30 Yudha Harimantoro T
  2008-10-11 15:12 ` Bill Davidsen
  0 siblings, 1 reply; 414+ messages in thread
From: Yudha Harimantoro T @ 2008-10-11  7:30 UTC (permalink / raw)
  To: linux-kernel; +Cc: davidsen

Date:	Fri, 10 Oct 2008 16:41:36 -0400
From:	Bill Davidsen


>Yudha Harimantoro T wrote:
>> Hi all,
>> Yesterday I build kernel 2.6.26.6 and it's run well. Today I got
>> 2.6.27 patch and try to build it.
>>
>> I build with `make oldconfig` and answer any question with default answer, I just press [enter].
>> I build with `make`. No error and all compiled.
>> Then I install with `make modules_install` and `make install`.
>>

> I realize that this is a low-probability thought, but did you:
> - apply the patch against 2.6.26 NOT 2.6.26.6
Yup, I've did it.
> - run make clean before applying the patch
I still need this for a pure 2.6.26? I'll try this.

>> After reboot the system I got 'kernel panic'.
>> This is the error picture :
>> http://www.ryht.co.cc/wordpress/wp-content/uploads/2008/10/pa101358.jpg
>> Is it a bugs?
>>
>> http://www.ryht.co.cc/wordpress/wp-content/uploads/2008/10/pa101353.jpg [2.6.26.6 run well]

> I keep configs in a separate place. I would first copy a 2.6.26 tree to a new directory (cp -rl linux-2.6.26 linux2.6.27) then be sure I had a clean copy with "make distclean" (or "make mrproper") and then apply the 2.6.27 patch. Then I would copy the 2.6.26 (or maybe 2.6.26.6) config to .config, and make the oldconfig.
> None of that is magic, it just keeps me from making common mistakes, lets me start with a clean 2.6.27, etc, etc.
> You mentioned oldconfig, but not starting back with a clean 2.6.26, which made me think of this.
Hm, I `cp /boot/config .config` in new kernel tree [2.6.27] for the
config. Do I make mistakes?

> --
> Bill Davidsen <davidsen@tmr.com>


Yudha_HT

^ permalink raw reply	[flat|nested] 414+ messages in thread
[parent not found: <0K6B0005EN54GNO0@l-daemon>]
[parent not found: <alpine.LFD.1.10.0807271037190.3486@nehalem.linux-foundation.org>]
* (no subject)
@ 2008-07-09 15:47 Mathieu Desnoyers
  2008-07-09 16:07 ` Eduard - Gabriel Munteanu
  0 siblings, 1 reply; 414+ messages in thread
From: Mathieu Desnoyers @ 2008-07-09 15:47 UTC (permalink / raw)
  To: Peter Zijlstra, Steven Rostedt
  Cc: Thomas Gleixner, Masami Hiramatsu, Frank Ch. Eigler, Hideo AOKI,
	Takashi Nishiie, Eduard - Gabriel Munteanu, akpm, Ingo Molnar,
	linux-kernel

Bcc: 
Subject: Re: [patch 05/15] LTTng instrumentation - scheduler (repost)
Reply-To: 
In-Reply-To: <20080709153434.GA9186@Krystal>
X-Editor: vi
X-Info: http://krystal.dyndns.org:8080
X-Operating-System: Linux/2.6.21.3-grsec (i686)
X-Uptime: 11:46:04 up 34 days, 20:27,  4 users,  load average: 2.95, 2.43,
	2.46

Hi Peter,

I noticed that my tracepoints are not exactly at the same location as
the trace_mark you have added for ftrace and that I do not pass the "rq"
parameter.  Should I change my patch to follow what you have in
linux-next ?

Mathieu

* Mathieu Desnoyers (mathieu.desnoyers@polymtl.ca) wrote:
> There were 2 rejects when I ported the patch to linux-next. Sorry. Here
> is a repost.
> 
> 
> Instrument the scheduler activity (sched_switch, migration, wakeups, wait for a
> task, signal delivery) and process/thread creation/destruction (fork, exit,
> kthread stop). Actually, kthread creation is not instrumented in this patch
> because it is architecture dependent. It allows to connect tracers such as
> ftrace which detects scheduling latencies, good/bad scheduler decisions. Tools
> like LTTng can export this scheduler information along with instrumentation of
> the rest of the kernel activity to perform post-mortem analysis on the scheduler
> activity.
> 
> About the performance impact of tracepoints (which is comparable to markers),
> even without immediate values optimizations, tests done by Hideo Aoki on ia64
> show no regression. His test case was using hackbench on a kernel where
> scheduler instrumentation (about 5 events in code scheduler code) was added.
> See the "Tracepoints" patch header for performance result detail.
> 
> Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
> CC: 'Peter Zijlstra' <peterz@infradead.org>
> CC: 'Steven Rostedt' <rostedt@goodmis.org>
> CC: Thomas Gleixner <tglx@linutronix.de>
> CC: Masami Hiramatsu <mhiramat@redhat.com>
> CC: "Frank Ch. Eigler" <fche@redhat.com>
> CC: 'Ingo Molnar' <mingo@elte.hu>
> CC: 'Hideo AOKI' <haoki@redhat.com>
> CC: Takashi Nishiie <t-nishiie@np.css.fujitsu.com>
> CC: Eduard - Gabriel Munteanu <eduard.munteanu@linux360.ro>
> ---
>  kernel/exit.c        |    6 ++++++
>  kernel/fork.c        |    3 +++
>  kernel/kthread.c     |    5 +++++
>  kernel/sched-trace.h |   43 +++++++++++++++++++++++++++++++++++++++++++
>  kernel/sched.c       |   11 ++++++-----
>  kernel/signal.c      |    3 +++
>  6 files changed, 66 insertions(+), 5 deletions(-)
> 
> Index: linux-2.6-lttng/kernel/kthread.c
> ===================================================================
> --- linux-2.6-lttng.orig/kernel/kthread.c	2008-07-09 11:27:01.000000000 -0400
> +++ linux-2.6-lttng/kernel/kthread.c	2008-07-09 11:27:08.000000000 -0400
> @@ -13,6 +13,7 @@
>  #include <linux/file.h>
>  #include <linux/module.h>
>  #include <linux/mutex.h>
> +#include "sched-trace.h"
>  
>  #define KTHREAD_NICE_LEVEL (-5)
>  
> @@ -187,6 +188,8 @@ int kthread_stop(struct task_struct *k)
>  	/* It could exit after stop_info.k set, but before wake_up_process. */
>  	get_task_struct(k);
>  
> +	trace_sched_kthread_stop(k);
> +
>  	/* Must init completion *before* thread sees kthread_stop_info.k */
>  	init_completion(&kthread_stop_info.done);
>  	smp_wmb();
> @@ -202,6 +205,8 @@ int kthread_stop(struct task_struct *k)
>  	ret = kthread_stop_info.err;
>  	mutex_unlock(&kthread_stop_lock);
>  
> +	trace_sched_kthread_stop_ret(ret);
> +
>  	return ret;
>  }
>  EXPORT_SYMBOL(kthread_stop);
> Index: linux-2.6-lttng/kernel/sched.c
> ===================================================================
> --- linux-2.6-lttng.orig/kernel/sched.c	2008-07-09 11:27:01.000000000 -0400
> +++ linux-2.6-lttng/kernel/sched.c	2008-07-09 11:27:56.000000000 -0400
> @@ -71,6 +71,7 @@
>  #include <linux/debugfs.h>
>  #include <linux/ctype.h>
>  #include <linux/ftrace.h>
> +#include "sched-trace.h"
>  
>  #include <asm/tlb.h>
>  #include <asm/irq_regs.h>
> @@ -1987,6 +1988,7 @@ void wait_task_inactive(struct task_stru
>  		 * just go back and repeat.
>  		 */
>  		rq = task_rq_lock(p, &flags);
> +		trace_sched_wait_task(p);
>  		running = task_running(rq, p);
>  		on_rq = p->se.on_rq;
>  		task_rq_unlock(rq, &flags);
> @@ -2275,6 +2277,7 @@ static int try_to_wake_up(struct task_st
>  
>  	smp_wmb();
>  	rq = task_rq_lock(p, &flags);
> +	trace_sched_try_wakeup(p);
>  	old_state = p->state;
>  	if (!(old_state & state))
>  		goto out;
> @@ -2457,6 +2460,7 @@ void wake_up_new_task(struct task_struct
>  	struct rq *rq;
>  
>  	rq = task_rq_lock(p, &flags);
> +	trace_sched_wakeup_new_task(p);
>  	BUG_ON(p->state != TASK_RUNNING);
>  	update_rq_clock(rq);
>  
> @@ -2647,11 +2651,7 @@ context_switch(struct rq *rq, struct tas
>  	struct mm_struct *mm, *oldmm;
>  
>  	prepare_task_switch(rq, prev, next);
> -	trace_mark(kernel_sched_schedule,
> -		"prev_pid %d next_pid %d prev_state %ld "
> -		"## rq %p prev %p next %p",
> -		prev->pid, next->pid, prev->state,
> -		rq, prev, next);
> +	trace_sched_switch(prev, next);
>  	mm = next->mm;
>  	oldmm = prev->active_mm;
>  	/*
> @@ -2884,6 +2884,7 @@ static void sched_migrate_task(struct ta
>  	    || unlikely(cpu_is_offline(dest_cpu)))
>  		goto out;
>  
> +	trace_sched_migrate_task(p, dest_cpu);
>  	/* force the process onto the specified CPU */
>  	if (migrate_task(p, dest_cpu, &req)) {
>  		/* Need to wait for migration thread (might exit: take ref). */
> Index: linux-2.6-lttng/kernel/exit.c
> ===================================================================
> --- linux-2.6-lttng.orig/kernel/exit.c	2008-07-09 11:27:01.000000000 -0400
> +++ linux-2.6-lttng/kernel/exit.c	2008-07-09 11:27:08.000000000 -0400
> @@ -46,6 +46,7 @@
>  #include <linux/resource.h>
>  #include <linux/blkdev.h>
>  #include <linux/task_io_accounting_ops.h>
> +#include "sched-trace.h"
>  
>  #include <asm/uaccess.h>
>  #include <asm/unistd.h>
> @@ -149,6 +150,7 @@ static void __exit_signal(struct task_st
>  
>  static void delayed_put_task_struct(struct rcu_head *rhp)
>  {
> +	trace_sched_process_free(container_of(rhp, struct task_struct, rcu));
>  	put_task_struct(container_of(rhp, struct task_struct, rcu));
>  }
>  
> @@ -1040,6 +1042,8 @@ NORET_TYPE void do_exit(long code)
>  
>  	if (group_dead)
>  		acct_process();
> +	trace_sched_process_exit(tsk);
> +
>  	exit_sem(tsk);
>  	exit_files(tsk);
>  	exit_fs(tsk);
> @@ -1524,6 +1528,8 @@ static long do_wait(enum pid_type type, 
>  	struct task_struct *tsk;
>  	int flag, retval;
>  
> +	trace_sched_process_wait(pid);
> +
>  	add_wait_queue(&current->signal->wait_chldexit,&wait);
>  repeat:
>  	/* If there is nothing that can match our critier just get out */
> Index: linux-2.6-lttng/kernel/fork.c
> ===================================================================
> --- linux-2.6-lttng.orig/kernel/fork.c	2008-07-09 11:27:01.000000000 -0400
> +++ linux-2.6-lttng/kernel/fork.c	2008-07-09 11:27:08.000000000 -0400
> @@ -56,6 +56,7 @@
>  #include <linux/proc_fs.h>
>  #include <linux/blkdev.h>
>  #include <linux/magic.h>
> +#include "sched-trace.h"
>  
>  #include <asm/pgtable.h>
>  #include <asm/pgalloc.h>
> @@ -1362,6 +1363,8 @@ long do_fork(unsigned long clone_flags,
>  	if (!IS_ERR(p)) {
>  		struct completion vfork;
>  
> +		trace_sched_process_fork(current, p);
> +
>  		nr = task_pid_vnr(p);
>  
>  		if (clone_flags & CLONE_PARENT_SETTID)
> Index: linux-2.6-lttng/kernel/signal.c
> ===================================================================
> --- linux-2.6-lttng.orig/kernel/signal.c	2008-07-09 11:25:24.000000000 -0400
> +++ linux-2.6-lttng/kernel/signal.c	2008-07-09 11:27:08.000000000 -0400
> @@ -26,6 +26,7 @@
>  #include <linux/freezer.h>
>  #include <linux/pid_namespace.h>
>  #include <linux/nsproxy.h>
> +#include "sched-trace.h"
>  
>  #include <asm/param.h>
>  #include <asm/uaccess.h>
> @@ -807,6 +808,8 @@ static int send_signal(int sig, struct s
>  	struct sigpending *pending;
>  	struct sigqueue *q;
>  
> +	trace_sched_signal_send(sig, t);
> +
>  	assert_spin_locked(&t->sighand->siglock);
>  	if (!prepare_signal(sig, t))
>  		return 0;
> Index: linux-2.6-lttng/kernel/sched-trace.h
> ===================================================================
> --- /dev/null	1970-01-01 00:00:00.000000000 +0000
> +++ linux-2.6-lttng/kernel/sched-trace.h	2008-07-09 11:27:08.000000000 -0400
> @@ -0,0 +1,43 @@
> +#ifndef _SCHED_TRACE_H
> +#define _SCHED_TRACE_H
> +
> +#include <linux/tracepoint.h>
> +
> +DEFINE_TRACE(sched_kthread_stop,
> +	TPPROTO(struct task_struct *t),
> +	TPARGS(t));
> +DEFINE_TRACE(sched_kthread_stop_ret,
> +	TPPROTO(int ret),
> +	TPARGS(ret));
> +DEFINE_TRACE(sched_wait_task,
> +	TPPROTO(struct task_struct *p),
> +	TPARGS(p));
> +DEFINE_TRACE(sched_try_wakeup,
> +	TPPROTO(struct task_struct *p),
> +	TPARGS(p));
> +DEFINE_TRACE(sched_wakeup_new_task,
> +	TPPROTO(struct task_struct *p),
> +	TPARGS(p));
> +DEFINE_TRACE(sched_switch,
> +	TPPROTO(struct task_struct *prev, struct task_struct *next),
> +	TPARGS(prev, next));
> +DEFINE_TRACE(sched_migrate_task,
> +	TPPROTO(struct task_struct *p, int dest_cpu),
> +	TPARGS(p, dest_cpu));
> +DEFINE_TRACE(sched_process_free,
> +	TPPROTO(struct task_struct *p),
> +	TPARGS(p));
> +DEFINE_TRACE(sched_process_exit,
> +	TPPROTO(struct task_struct *p),
> +	TPARGS(p));
> +DEFINE_TRACE(sched_process_wait,
> +	TPPROTO(struct pid *pid),
> +	TPARGS(pid));
> +DEFINE_TRACE(sched_process_fork,
> +	TPPROTO(struct task_struct *parent, struct task_struct *child),
> +	TPARGS(parent, child));
> +DEFINE_TRACE(sched_signal_send,
> +	TPPROTO(int sig, struct task_struct *p),
> +	TPARGS(sig, p));
> +
> +#endif
> -- 
> Mathieu Desnoyers
> OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68

-- 
Mathieu Desnoyers
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68

^ permalink raw reply	[flat|nested] 414+ messages in thread
* (no subject)
@ 2008-05-20 12:34 Lukas Hejtmanek
  2008-05-20 12:40 ` Oliver Neukum
  0 siblings, 1 reply; 414+ messages in thread
From: Lukas Hejtmanek @ 2008-05-20 12:34 UTC (permalink / raw)
  To: Oliver Neukum
  Cc: Rafael J. Wysocki, Linux Kernel Mailing List, stern, greg, linux-usb

<stern@rowland.harvard.edu>, Greg KH <greg@kroah.com>
Bcc: 
Subject: Re: [Bug #10630] USB devices plugged into dock are not discoverred
	until reload of ehci-hcd
Reply-To: 
In-Reply-To: <200805201327.34678.oliver@neukum.org>
X-echelon: NSA, CIA, CI5, MI5, FBI, KGB, BIS, Plutonium, Bin Laden, bomb

On Tue, May 20, 2008 at 01:27:34PM +0200, Oliver Neukum wrote:
> > done.
> > http://bugzilla.kernel.org/show_bug.cgi?id=10630
> 
> Aha. Thanks.
> Please recompile without CONFIG_USB_SUSPEND

Hm, without USB_SUSPEND it works. So what next, considered fixed or any
further investigation is needed?

-- 
Lukáš Hejtmánek

^ permalink raw reply	[flat|nested] 414+ messages in thread
* (no subject)
@ 2008-04-09  8:45 Andreas Grimm
  2008-04-10  1:14 ` Lee Revell
  0 siblings, 1 reply; 414+ messages in thread
From: Andreas Grimm @ 2008-04-09  8:45 UTC (permalink / raw)
  To: linux-kernel

Hello everybody,
 
 i got a weird problem with one of my servers. It's a Intel SR2500AL with 32GB of RAM. 
 Looking at the memory usage of the system, something is going totally wrong. The crucial numbers from /proc/meminfo are:
 
 MemTotal:     33265916 kB
 MemFree:        416168 kB
 Inactive:     24630428 kB   (24GB? whooaaa)
 
 Another system with only 16GB, same amount of users and load, shows a more normal behaviour:
 
 MemTotal:     16619808 kB
 MemFree:       6912676 kB
 Inactive:      1774364 kB
 
 Why does the 32GB-System have this plenty of inactive memory. Is there a way to find out, what the kernel is holding in readiness (that's the definition of inactive memory afaik)?
 
 OS: SLES 10 SP1
 Kernel : 2.6.16.27-0.9-bigsmp
 
 Thanks in advance.
 
 Andreas Grimm




      ____________________________________________________________________________________
You rock. That's why Blockbuster's offering you one month of Blockbuster Total Access, No Cost.  
http://tc.deals.yahoo.com/tc/blockbuster/text5.com


^ permalink raw reply	[flat|nested] 414+ messages in thread
* (no subject)
@ 2008-02-03 11:13 am kara
  2008-02-03 18:23 ` Benny Halevy
  0 siblings, 1 reply; 414+ messages in thread
From: am kara @ 2008-02-03 11:13 UTC (permalink / raw)
  To: linux-kernel

hello,

If kernel does kmap_atomic(temporary kernel mapping)
on behalf of a process by a cpu, does the process will
continue to run and no other process can be scheduled
to switch it off?(till kunmap_atomic is done)

 


      ____________________________________________________________________________________
Looking for last minute shopping deals?  
Find them fast with Yahoo! Search.  http://tools.search.yahoo.com/newsearch/category.php?category=shopping


^ permalink raw reply	[flat|nested] 414+ messages in thread
* (no subject)
@ 2007-11-10  1:18 Luck, Tony
  2007-11-10  1:42 ` Eric Dumazet
  0 siblings, 1 reply; 414+ messages in thread
From: Luck, Tony @ 2007-11-10  1:18 UTC (permalink / raw)
  To: LKML; +Cc: dada1

Just pulled latest git tree from Linus and a few ia64 configurations
(anything with CONFIG_NUMA=y) won't build.

The offending commit appears to be:

    230140cffa7feae90ad50bf259db1fa07674f3a7

Here's the error messages from the compiler:

  CC [M]  drivers/infiniband/core/cma.o
In file included from include/net/tcp.h:35,
                 from drivers/infiniband/core/cma.c:40:
include/net/inet_hashtables.h: In function `inet_ehash_locks_alloc':
include/net/inet_hashtables.h:165: error: implicit declaration of
function `vmalloc'
include/net/inet_hashtables.h:165: warning: assignment makes pointer
from integer without a cast
include/net/inet_hashtables.h: In function `inet_ehash_locks_free':
include/net/inet_hashtables.h:186: error: implicit declaration of
function `vfree'
make[3]: *** [drivers/infiniband/core/cma.o] Error 1


-Tony

^ permalink raw reply	[flat|nested] 414+ messages in thread
* Re: [PATCH 0/24] make atomic_read() behave consistently across all architectures
@ 2007-08-14 23:04 Chris Snook
  2007-08-15  6:49 ` Herbert Xu
  0 siblings, 1 reply; 414+ messages in thread
From: Chris Snook @ 2007-08-14 23:04 UTC (permalink / raw)
  To: Satyam Sharma
  Cc: Christoph Lameter, Linux Kernel Mailing List, linux-arch,
	torvalds, netdev, Andrew Morton, ak, heiko.carstens, davem,
	schwidefsky, wensong, horms, wjiang, cfriesen, zlynx, rpjday,
	jesper.juhl, segher

Satyam Sharma wrote:
> 
> On Tue, 14 Aug 2007, Christoph Lameter wrote:
> 
>> On Thu, 9 Aug 2007, Chris Snook wrote:
>>
>>> This patchset makes the behavior of atomic_read uniform by removing the
>>> volatile keyword from all atomic_t and atomic64_t definitions that currently
>>> have it, and instead explicitly casts the variable as volatile in
>>> atomic_read().  This leaves little room for creative optimization by the
>>> compiler, and is in keeping with the principles behind "volatile considered
>>> harmful".
>> volatile is generally harmful even in atomic_read(). Barriers control
>> visibility and AFAICT things are fine.
> 
> Frankly, I don't see the need for this series myself either. Personal
> opinion (others may differ), but I consider "volatile" to be a sad /
> unfortunate wart in C (numerous threads on this list and on the gcc
> lists/bugzilla over the years stand testimony to this) and if we _can_
> steer clear of it, then why not -- why use this ill-defined primitive
> whose implementation has often differed over compiler versions and
> platforms? Granted, barrier() _is_ heavy-handed in that it makes the
> optimizer forget _everything_, but then somebody did post a forget()
> macro on this thread itself ...
> 
> [ BTW, why do we want the compiler to not optimize atomic_read()'s in
>   the first place? Atomic ops guarantee atomicity, which has nothing
>   to do with "volatility" -- users that expect "volatility" from
>   atomic ops are the ones who must be fixed instead, IMHO. ]

Because atomic operations are generally used for synchronization, which requires 
volatile behavior.  Most such codepaths currently use an inefficient barrier(). 
  Some forget to and we get bugs, because people assume that atomic_read() 
actually reads something, and atomic_write() actually writes something.  Worse, 
these are architecture-specific, even compiler version-specific bugs that are 
often difficult to track down.

	-- Chris

^ permalink raw reply	[flat|nested] 414+ messages in thread
* (no subject)
@ 2007-08-07 16:34 Brian J. Murrell
  2007-08-09 20:33 ` Mark Lord
  0 siblings, 1 reply; 414+ messages in thread
From: Brian J. Murrell @ 2007-08-07 16:34 UTC (permalink / raw)
  To: linux-kernel

[-- Attachment #1: Type: text/plain, Size: 11470 bytes --]

I am using Ubuntu Gutsy, which is the in-development branch heading for
their next stable release.

I have noticed that since some kernel release post-2.6.20 I have been
unable to mount my /boot partition:

$ sudo strace -f mount /dev/hda1 /mnt/foo
execve("/bin/mount", ["mount", "/dev/hda1", "/mnt/foo"], [/* 41 vars*/])= 0
brk(0)                                  = 0x8062000
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory)
mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7fbc000
access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY)      = 4
fstat64(4, {st_mode=S_IFREG|0644, st_size=91976, ...}) = 0
mmap2(NULL, 91976, PROT_READ, MAP_PRIVATE, 4, 0) = 0xb7fa5000
close(4)                                = 0
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory)
open("/lib/tls/i686/cmov/libc.so.6", O_RDONLY) = 4
read(4, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\260a\1"..., 512) = 512
fstat64(4, {st_mode=S_IFREG|0644, st_size=1339816, ...}) = 0
mmap2(NULL, 1349136, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 4, 0) = 0xb7e5b000
mmap2(0xb7f9f000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 4, 0x143) = 0xb7f9f000
mmap2(0xb7fa2000, 9744, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb7fa2000
close(4)                                = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7e5a000
set_thread_area({entry_number:-1 -> 6, base_addr:0xb7e5a6b0, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, useable:1}) = 0
mprotect(0xb7f9f000, 4096, PROT_READ)   = 0
munmap(0xb7fa5000, 91976)               = 0
brk(0)                                  = 0x8062000
brk(0x8083000)                          = 0x8083000
open("/usr/lib/locale/locale-archive", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
open("/usr/share/locale/locale.alias", O_RDONLY) = 4
fstat64(4, {st_mode=S_IFREG|0644, st_size=2586, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7fbb000
read(4, "# Locale name alias data base.\n#"..., 1024) = 1024
read(4, "ies are case independent.\n\n# Not"..., 1024) = 1024
read(4, ".euc \tko_KR.eucKR\nko_KR\t\tko_KR.e"..., 1024) = 538
read(4, "", 1024)                       = 0
close(4)                                = 0
munmap(0xb7fbb000, 4096)                = 0
open("/usr/lib/locale/en_CA.UTF-8/LC_IDENTIFICATION", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/lib/locale/en_CA.utf8/LC_IDENTIFICATION", O_RDONLY) = 4
fstat64(4, {st_mode=S_IFREG|0644, st_size=363, ...}) = 0
mmap2(NULL, 363, PROT_READ, MAP_PRIVATE, 4, 0) = 0xb7fbb000
close(4)                                = 0
open("/usr/lib/gconv/gconv-modules.cache", O_RDONLY) = 4
fstat64(4, {st_mode=S_IFREG|0644, st_size=25486, ...}) = 0
mmap2(NULL, 25486, PROT_READ, MAP_SHARED, 4, 0) = 0xb7fb4000
close(4)                                = 0
open("/usr/lib/locale/en_CA.UTF-8/LC_MEASUREMENT", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/lib/locale/en_CA.utf8/LC_MEASUREMENT", O_RDONLY) = 4
fstat64(4, {st_mode=S_IFREG|0644, st_size=23, ...}) = 0
mmap2(NULL, 23, PROT_READ, MAP_PRIVATE, 4, 0) = 0xb7fb3000
close(4)                                = 0
open("/usr/lib/locale/en_CA.UTF-8/LC_TELEPHONE", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/lib/locale/en_CA.utf8/LC_TELEPHONE", O_RDONLY) = 4
fstat64(4, {st_mode=S_IFREG|0644, st_size=51, ...}) = 0
mmap2(NULL, 51, PROT_READ, MAP_PRIVATE, 4, 0) = 0xb7fb2000
close(4)                                = 0
open("/usr/lib/locale/en_CA.UTF-8/LC_ADDRESS", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/lib/locale/en_CA.utf8/LC_ADDRESS", O_RDONLY) = 4
fstat64(4, {st_mode=S_IFREG|0644, st_size=127, ...}) = 0
mmap2(NULL, 127, PROT_READ, MAP_PRIVATE, 4, 0) = 0xb7fb1000
close(4)                                = 0
open("/usr/lib/locale/en_CA.UTF-8/LC_NAME", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/lib/locale/en_CA.utf8/LC_NAME", O_RDONLY) = 4
fstat64(4, {st_mode=S_IFREG|0644, st_size=62, ...}) = 0
mmap2(NULL, 62, PROT_READ, MAP_PRIVATE, 4, 0) = 0xb7fb0000
close(4)                                = 0
open("/usr/lib/locale/en_CA.UTF-8/LC_PAPER", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/lib/locale/en_CA.utf8/LC_PAPER", O_RDONLY) = 4
fstat64(4, {st_mode=S_IFREG|0644, st_size=34, ...}) = 0
mmap2(NULL, 34, PROT_READ, MAP_PRIVATE, 4, 0) = 0xb7faf000
close(4)                                = 0
open("/usr/lib/locale/en_CA.UTF-8/LC_MESSAGES", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/lib/locale/en_CA.utf8/LC_MESSAGES", O_RDONLY) = 4
fstat64(4, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
close(4)                                = 0
open("/usr/lib/locale/en_CA.utf8/LC_MESSAGES/SYS_LC_MESSAGES", O_RDONLY) = 4
fstat64(4, {st_mode=S_IFREG|0644, st_size=54, ...}) = 0
mmap2(NULL, 54, PROT_READ, MAP_PRIVATE, 4, 0) = 0xb7fae000
close(4)                                = 0
open("/usr/lib/locale/en_CA.UTF-8/LC_MONETARY", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/lib/locale/en_CA.utf8/LC_MONETARY", O_RDONLY) = 4
fstat64(4, {st_mode=S_IFREG|0644, st_size=286, ...}) = 0
mmap2(NULL, 286, PROT_READ, MAP_PRIVATE, 4, 0) = 0xb7fad000
close(4)                                = 0
open("/usr/lib/locale/en_CA.UTF-8/LC_COLLATE", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/lib/locale/en_CA.utf8/LC_COLLATE", O_RDONLY) = 4
fstat64(4, {st_mode=S_IFREG|0644, st_size=880094, ...}) = 0
mmap2(NULL, 880094, PROT_READ, MAP_PRIVATE, 4, 0) = 0xb7d83000
close(4)                                = 0
open("/usr/lib/locale/en_CA.UTF-8/LC_TIME", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/lib/locale/en_CA.utf8/LC_TIME", O_RDONLY) = 4
fstat64(4, {st_mode=S_IFREG|0644, st_size=2451, ...}) = 0
mmap2(NULL, 2451, PROT_READ, MAP_PRIVATE, 4, 0) = 0xb7fac000
close(4)                                = 0
open("/usr/lib/locale/en_CA.UTF-8/LC_NUMERIC", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/lib/locale/en_CA.utf8/LC_NUMERIC", O_RDONLY) = 4
fstat64(4, {st_mode=S_IFREG|0644, st_size=54, ...}) = 0
mmap2(NULL, 54, PROT_READ, MAP_PRIVATE, 4, 0) = 0xb7fab000
close(4)                                = 0
open("/usr/lib/locale/en_CA.UTF-8/LC_CTYPE", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/lib/locale/en_CA.utf8/LC_CTYPE", O_RDONLY) = 4
fstat64(4, {st_mode=S_IFREG|0644, st_size=238336, ...}) = 0
mmap2(NULL, 238336, PROT_READ, MAP_PRIVATE, 4, 0) = 0xb7d48000
close(4)                                = 0
umask(022)                              = 022
open("/dev/null", O_RDWR|O_LARGEFILE)   = 4
close(4)                                = 0
getuid32()                              = 0
geteuid32()                             = 0
lstat64("/etc/mtab", {st_mode=S_IFREG|0644, st_size=1136, ...}) = 0
stat64("/dev/hda1", {st_mode=S_IFBLK|0660, st_rdev=makedev(3, 1), ...}) = 0
rt_sigprocmask(SIG_BLOCK, ~[TRAP SEGV RTMIN RT_1], NULL, 8) = 0
open("/dev/hda1", O_RDONLY|O_LARGEFILE) = 4
ioctl(4, BLKGETSIZE64, 0xbf80f540)      = 0
_llseek(4, 41025536, [41025536], SEEK_SET) = 0
read(4, "#=\353\177\374A\305\366d\332&\230\373\222\\\353\3331\r"..., 2048) = 2048
brk(0x80aa000)                          = 0x80aa000
_llseek(4, 0, [0], SEEK_SET)            = 0
read(4, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 2048) = 2048
_llseek(4, 0, [0], SEEK_SET)            = 0
read(4, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 6144) = 6144
_llseek(4, 41093632, [41093632], SEEK_SET) = 0
read(4, "e\262\321\332\273j\242\335\317*\nlb\237T\237\212\236\247"..., 512) = 512
_llseek(4, 41093120, [41093120], SEEK_SET) = 0
read(4, ">\270\20XK\177\307\233\334j\315\357ac\235\360\225\276\234"..., 512) = 512
_llseek(4, 41093632, [41093632], SEEK_SET) = 0
read(4, "e\262\321\332\273j\242\335\317*\nlb\237T\237\212\236\247"..., 512) = 512
_llseek(4, 41093120, [41093120], SEEK_SET) = 0
read(4, ">\270\20XK\177\307\233\334j\315\357ac\235\360\225\276\234"..., 512) = 512
_llseek(4, 41061888, [41061888], SEEK_SET) = 0
read(4, "\327\312Z\320s/\201\322\241\274\216\374*\263\1\7\\\220"..., 512) = 512
_llseek(4, 40963584, [40963584], SEEK_SET) = 0
read(4, "ODUX\237\253{I\24\216\372\204\213\3525\316\20\341\274\327"..., 512) = 512
_llseek(4, 40963072, [40963072], SEEK_SET) = 0
read(4, ":<\217\6\371F\16M\267f\260\265?uH\3656gNJ\v\30\253\350"..., 512) = 512
_llseek(4, 41085952, [41085952], SEEK_SET) = 0
read(4, "~\360\373F>\247\346bp\266gA\231\373\24\v0\307\37\222G$"..., 512) = 512
_llseek(4, 40889856, [40889856], SEEK_SET) = 0
read(4, "KD\276\330\26\36\266U\373\332\255=\3440\22c\323\276\266"..., 512) = 512
_llseek(4, 41088512, [41088512], SEEK_SET) = 0
read(4, "o\331\251yn\365\25669S!} \1\303\334\31\264K\27A)p\341s"..., 512) = 512
_llseek(4, 41093632, [41093632], SEEK_SET) = 0
read(4, "e\262\321\332\273j\242\335\317*\nlb\237T\237\212\236\247"..., 512) = 512
_llseek(4, 0, [0], SEEK_SET)            = 0
read(4, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 8192) = 8192
_llseek(4, 0, [0], SEEK_SET)            = 0
read(4, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 16384) = 16384
brk(0x8099000)                          = 0x8099000
brk(0x8089000)                          = 0x8089000
close(4)                                = 0
stat64("/sbin/mount.ext3", 0xbf80f484)  = -1 ENOENT (No such file or directory)
mount("/dev/hda1", "/mnt/foo", "ext3", MS_MGC_VAL, NULL) = -1 EBUSY (Device or resource busy)
rt_sigprocmask(SIG_UNBLOCK, ~[TRAP SEGV RTMIN RT_1], NULL, 8) = 0
write(2, "mount: /dev/hda1 already mounted"..., 50mount: /dev/hda1 already mounted or /mnt/foo busy) = 50
umask(077)                              = 022
open("/etc/mtab", O_RDONLY|O_LARGEFILE) = 4
umask(022)                              = 077
fstat64(4, {st_mode=S_IFREG|0644, st_size=1136, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7d47000
read(4, "/dev/dm-20 / ext3 rw,errors=remo"..., 1024) = 1024
read(4, "ib/nfs/rpc_pipefs rpc_pipefs rw "..., 1024) = 112
read(4, "", 1024)                       = 0
close(4)                                = 0
munmap(0xb7d47000, 4096)                = 0
exit_group(32)                          = ?
Process 27016 detached

All other block devices (all LVM LVs) seem to mount with no problems.

Certainly I leave open the possibility of pilot error (by either me or
Ubuntu) but I don't know how to even see why/where/what could be going
wrong.

/proc/mounts does not show the device mounted:

$ grep hda /proc/mounts
$ 

and fuser and lsof doesn't show anything using the mount point:

$ fuser /mnt/foo
$ sudo lsof | grep /mnt/foo
$ 

Nor does lsof show /dev/hda (device 3,1) in use:

$ sudo lsof | grep -e hda -e 3,1
$ 

So I'm kind of perplexed as to what to try next in how to debug
this?

Any ideas?  Thanx in advance.

b.

-- 
A day in the yard with my son is just like a day at work.  He goes
hunting around for stuff and brings it back to me and says: "Hey Dad,
look what I found.  The money is for me and the screw is for you."

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

^ permalink raw reply	[flat|nested] 414+ messages in thread
[parent not found: <FC1D1B23302A22499C60C967336B2AE00186B15C@pdsmsx411.ccr.corp.intel.com>]
* (no subject)
@ 2007-02-09  6:29 Priyanka Sharma
  2007-02-10  2:41 ` hackmiester (Hunter Fuller)
  0 siblings, 1 reply; 414+ messages in thread
From: Priyanka Sharma @ 2007-02-09  6:29 UTC (permalink / raw)
  To: linux-kernel

unsubscribe linux-kernel

-- 
Priyanka
202.141.151.80/~priyanka

^ permalink raw reply	[flat|nested] 414+ messages in thread
* Re:
@ 2006-08-16  9:30 shane
  0 siblings, 0 replies; 414+ messages in thread
From: shane @ 2006-08-16  9:30 UTC (permalink / raw)
  To: linux-kernel

Hello,

Your mail to shane@bcs.org.uk was caught by the
SpamAssassin filter running on the bcs.org.uk mail system.

To confirm that your mail is genuine, please click this
link, or paste it into your browser:
https://bcsnet.bcs.org.uk/approve.php?c=2c9bc71e222cc1265421a982

You will not have to do this again for any mail sent
to this recipient (shane@bcs.org.uk).

Thank you.

-- 
British Computer Society - www.bcs.org.uk
Email Services from gradwell dot com - www.gradwell.com

^ permalink raw reply	[flat|nested] 414+ messages in thread
* (no subject)
@ 2006-05-16 10:34 Chris Boot
  2006-05-16 12:34 ` Arnaldo Carvalho de Melo
  0 siblings, 1 reply; 414+ messages in thread
From: Chris Boot @ 2006-05-16 10:34 UTC (permalink / raw)
  To: kernel list, netdev; +Cc: grsecurity

Hi,

I've just seen the following assertions pop out of one of my servers  
running 2.6.16.9 with grsecurity. I've searched the archives of LKML  
and netdev and I've only found posts relating to 2.6.9, after which  
some related bugs were fixed... It looks like these bugs are related  
to e1000, which is the driver I'm using. The system was running 24  
days before these appeared and it's still running absolutely fine.

May 16 09:15:12 baldrick kernel: [6442250.504000] KERNEL: assertion (! 
sk->sk_forward_alloc) failed at net/core/stream.c (283)
May 16 09:15:12 baldrick kernel: [6442250.513000] KERNEL: assertion (! 
sk->sk_forward_alloc) failed at net/ipv4/af_inet.c (150)

baldrick bootc # ethtool -k eth0
Offload parameters for eth0:
rx-checksumming: on
tx-checksumming: on
scatter-gather: on
tcp segmentation offload: on

Many thanks,
Chris

PS: I'm not subscribed to netdev.

-- 
Chris Boot
bootc@bootc.net
http://www.bootc.net/


^ permalink raw reply	[flat|nested] 414+ messages in thread
* Re:
@ 2006-03-11  1:00 Alec
  0 siblings, 0 replies; 414+ messages in thread
From: Alec @ 2006-03-11  1:00 UTC (permalink / raw)
  To: linux-kernel

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=unknown-8bit, Size: 909 bytes --]


Hey whats up,

All the maajor barands like aR0lex, aTag uHeuer, aCart ier etc.

Dite for the Rep lica wautches, L0w   ePRi ces we 0 ffer.

Your human instinct is to be recognized.

iAffordable imitations make you look erich, ufraction of the oC0St. 

========================================================================

COPY the Address below and paste in your WEBa browser:


afraidness.justworlds.com

========================================================================


I am the woman who worked in the field .
Despite overall sluggish wage growth,.
Not physiognomy alone, nor brain alone, is worthy for the muse—I say the-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

^ permalink raw reply	[flat|nested] 414+ messages in thread
* Re: Re:
@ 2006-03-03 14:54 Kennedy
  0 siblings, 0 replies; 414+ messages in thread
From: Kennedy @ 2006-03-03 14:54 UTC (permalink / raw)
  To: linux-kernel

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="us-ascii", Size: 653 bytes --]


How have you been,

A11          Pre#scr!pt!0ns       are filled by          L!#cens#ed        Ph@r#m@!_sts.

We have Special    0ff3rss      and some  New       Pr0ducctss.

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

copy the address below and paste in e your web browser:

bibliosoph.iyodopack.com

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++


A sour Scotswoman called Hooch..
A child—with a most knowing eye..
(With my lips soothing thee, adding, I whisper, .
push the "Perform Currency Conversion" button..
Still bar you the way, and deny you life --  .

Thanks Alot,

Dudley Templeton 

^ permalink raw reply	[flat|nested] 414+ messages in thread
* Re:
@ 2006-02-23 12:16 Norberto
  0 siblings, 0 replies; 414+ messages in thread
From: Norberto @ 2006-02-23 12:16 UTC (permalink / raw)
  To: linux-kernel


Hey,

R3F1N4NC3         your current           L0A`NNNN.

R3F1N@NC3          your          m0rrt g@@gee          at a better      Ra=
a te.


$340k for 330 pm, we r    Justi    Giving    away

******************************************************************

COPY the Address below and paste in your BROiWSER:

Aphelinus.lowestpay.net

******************************************************************


She only looked away for a few seconds to guide her fingers in peeling the=
=20.
(With my lips soothing thee, adding, I whisper,=20.
Considerest thou alone the burial of the stars?=20.
After she'd done her ledger she would clamber into her hammock and read a =
book for a couple of hours..
If you'll just tell me so --.


Thanks,
Morris Kaufmann=20

^ permalink raw reply	[flat|nested] 414+ messages in thread
* Re: Re:
@ 2006-02-18 16:04 Donne
  0 siblings, 0 replies; 414+ messages in thread
From: Donne @ 2006-02-18 16:04 UTC (permalink / raw)
  To: linux-kernel

Good day sir,

Loow cost name-brand prei scri iptions shipped to your door lightning quic=
k!

Fruee delivery and unique packaging.

--------------------------------

copy the address below and paste in a your web browser:

arrestor.newtechtown.com/?zz=3Dlowcost

--------------------------------

vali d  for 24 hars.


'Well if you had to think about it now, what would you think?'.
when we were sharing rooms as bachelors in Baker Street..
So shake the very Heaven on high.
Of Bobo the Bear..
His books are all jammed in the closet,.

Goodbye,

Hugh Jackson=20

^ permalink raw reply	[flat|nested] 414+ messages in thread
* Re:
@ 2006-02-04 14:33 Ira Jackson 
  0 siblings, 0 replies; 414+ messages in thread
From: Ira Jackson  @ 2006-02-04 14:33 UTC (permalink / raw)
  To: linux-admin, linux-fsdevel, linux-kernel

Hi,

We cut your payment by 45%

Re aF ainancing can give you extra acash for the things you've always want=
ed to do. Like starting a home business or paying for college.


U S  $ 300 ,000       aL0 aANS        are avai lable for only $277 / month=
! WE'RE aPRACT ICALLY aGIVIaNG aAWAY MOaNEY!

---------------------------------

COPY the Addreass below and paste in your WEaB BROaWSER:

carucal.realquikx.com

----------------------------------

V a l id for 24 Hrs.

I need not start -- you're sure --.
professor and former chief of GE's Crotonville leadership development prog=
ram..
Of Life immense in passion, pulse, and power,=20.
No safety , no love, no respect was I due..
Yet shining like the sun with love's true light.=20.


Thanks Alot,
Elsa Robb

^ permalink raw reply	[flat|nested] 414+ messages in thread
* (no subject)
@ 2006-01-27 10:05 sarat
  2006-01-27 10:09 ` Arjan van de Ven
  0 siblings, 1 reply; 414+ messages in thread
From: sarat @ 2006-01-27 10:05 UTC (permalink / raw)
  To: linux-kernel

please clarify the error

insmod: error inserting 'firewall.ko': -1 Invalid module format

^ permalink raw reply	[flat|nested] 414+ messages in thread
* Re: system keeps freezing once every 24 hours / random apps crashing
@ 2005-12-31  0:27 Alistair John Strachan
  2005-12-31  0:42 ` Mark v Wolher
  0 siblings, 1 reply; 414+ messages in thread
From: Alistair John Strachan @ 2005-12-31  0:27 UTC (permalink / raw)
  To: Mark v Wolher; +Cc: Lee Revell, Folkert van Heusden, Jesper Juhl, Linux Kernel

On Saturday 31 December 2005 00:20, Mark v Wolher wrote:
[snip]
> >
> > This is good news -- you stand a better chance of achieving the stability
> > you require by eliminating variables. VMWare and NVIDIA are useful
> > softwares, and I would not deny that, but they are closed source and thus
> > any conflicts resulting from their use are not necessary LKML material
> > (however, if the interaction is generic and is as a result of a kernel
> > bug, then the maintainer would very much like to hear it).
>
> Okay, i have something interesting now, i only had the nvidia module
> loaded so my x-configuration starts up as usual. (not saying the nvidia
> module is flawless, i'm sure it still contains bugs)
> But here is the crash info, this time it was mozilla, i think this
> speaks more hehe :
>
> Dec 31 00:55:28 localhost kernel: mm/memory.c:106: bad pgd 061f0c08.
> Dec 31 00:55:28 localhost kernel: mm/memory.c:106: bad pgd 06b96000.
> Dec 31 00:55:28 localhost kernel: mm/memory.c:106: bad pgd 18000bf8.
> Dec 31 00:55:28 localhost kernel: ------------[ cut here ]------------
> Dec 31 00:55:28 localhost kernel: kernel BUG at mm/mmap.c:2214!
> Dec 31 00:55:28 localhost kernel: invalid operand: 0000 [#1]
> Dec 31 00:55:28 localhost kernel: SMP
> Dec 31 00:55:28 localhost kernel: Modules linked in: nvidia

Steady and sure progress. Now, the trace below doesn't explicitly mention any 
nvidia symbols, but this line must disappear before anybody will bother to 
read your report.

Remove the module. This does not mean unload, this means "never load in the 
first place". Then reproduce the problem. If you are successful, send a new 
email (not pinned to this thread) with a subject a la "kernel BUG at 
mm/mmap.c:2214". State that the kernel is not tainted.

At this point all you can do is wait. Good luck!

-- 
Cheers,
Alistair.

'No sense being pessimistic, it probably wouldn't work anyway.'
Third year Computer Science undergraduate.
1F2 55 South Clerk Street, Edinburgh, UK.

^ permalink raw reply	[flat|nested] 414+ messages in thread
* (no subject)
@ 2005-12-02 16:03 Yu, Luming
  2005-12-02 16:46 ` Dmitry Torokhov
  2005-12-02 20:11 ` Re: Miloslav Trmac
  0 siblings, 2 replies; 414+ messages in thread
From: Yu, Luming @ 2005-12-02 16:03 UTC (permalink / raw)
  To: Dmitry Torokhov, Linus Torvalds
  Cc: Vojtech Pavlik, Andrew Morton, Linux Kernel Mailing List

>Subject: [git pull 02/14] Add Wistron driver
>
>Input: add Wistron driver
>
>A driver for laptop buttons using an x86 BIOS interface that is
>apparently used on quite a few laptops and seems to be originating
>from Wistron.
>
>This driver currently "knows" only about Fujitsu-Siemens Amilo 
>Pro V2000
>(i.e. it can detect the laptop using DMI and it contains the
>keycode->key meaning mapping for this laptop) and Xeron SonicPro X 155G
>(probably can't be reliably autodetected, requires a module parameter),
>adding other laptops should be easy.
>
>In addition to reporting button presses to the input layer the driver
>also allows enabling/disabling the embedded wireless NIC (using the
>"Wifi" button); this is done using the same BIOS interface, so it seems
>only logical to keep the implementation together.  Any flexibility
>possibly gained by allowing users to remap the function of the "Wifi"
>button is IMHO not worth it when weighted against the necessity to run
>an user-space daemon to convert button presses to wifi state changes.
>
>Signed-off-by: Miloslav Trmac <mitr@volny.cz>
>Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
>---
>

I just tested module wistron_btn on  one Acer Aspire laptop after 
adding one dmi entry.  The wistron_btn found BIOS interfaces.
One visible error is the bluetooth light won't turn on upon 
stroking bluetooth button.
Without wistron_btn module, the bluetooth light works.
 with acpi enabled, I didn't try acpi disabled)

wistron_btn polls a cmos address to detect hotkey event.  It 
is not necessary, because there do have ACPI interrupt triggered upon 
hotkeys.  

So, my suggestion is to disable this module when ACPI enabled.
We need to implement hotkey support from ACPI subsystem for my
Acer aspire laptop.

--- linux-2.6.15-rc3/drivers/input/misc/Kconfig.0	2005-12-02
10:08:33.000000000 -0700
+++ linux-2.6.15-rc3/drivers/input/misc/Kconfig	2005-12-02
10:08:58.000000000 -0700
@@ -42,7 +42,7 @@
 
 config INPUT_WISTRON_BTNS
 	tristate "x86 Wistron laptop button interface"
-	depends on X86 && !X86_64
+	depends on X86 && !X86_64 && !ACPI
 	help
 	  Say Y here for support of Winstron laptop button interface,
used on
 	  laptops of various brands, including Acer and Fujitsu-Siemens.


^ permalink raw reply	[flat|nested] 414+ messages in thread
* (no subject)
@ 2005-11-09 16:13 Nestor Velazquez
  2005-11-09 16:17 ` Alejandro Bonilla
  0 siblings, 1 reply; 414+ messages in thread
From: Nestor Velazquez @ 2005-11-09 16:13 UTC (permalink / raw)
  To: linux-kernel

Hola necesito informacion sobre linux gracias


Velazquez Nestor

^ permalink raw reply	[flat|nested] 414+ messages in thread
* (no subject)
@ 2005-09-21 13:20 Robert.Boermans
  2005-09-21 13:27 ` Denis Vlasenko
  0 siblings, 1 reply; 414+ messages in thread
From: Robert.Boermans @ 2005-09-21 13:20 UTC (permalink / raw)
  To: linux-kernel

Hello, 

I noticed that the bogomips results for the two cores on my machine are 
consistently not the same, the second one is always reported slightly 
faster, it's a small difference and I saw the same in a posted dmesg from 
somebody else on the list. Which made me wonder: 

Shouldn't they be the same, as the cores run from the same clock? 
Could it be a bug in the bogomips calculation which could make some of the 
short time-out stuff fail?
Could this be related to the tsc synchronisation stuff mentioned in the 
lost ticks - TSC timer thread? 

Regards, 

Robert Boermans. 
PS nothing actually fails on my system because of this, I just thought it 
was odd. Although I do sometimes get the clock runs at double speed 
problem but only after at least one day uptime, but I reboot most days for 
games anyway. 

^ permalink raw reply	[flat|nested] 414+ messages in thread
* (no subject)
@ 2005-06-28  9:18 d binderman
  2005-06-28 11:03 ` Andrew Morton
  0 siblings, 1 reply; 414+ messages in thread
From: d binderman @ 2005-06-28  9:18 UTC (permalink / raw)
  To: linux-kernel


Hello there,

I just tried to compile the Linux Kernel version 2.6.11.12
with the gcc 4.0 compiler. The compiler said

drivers/net/depca.c:1829: warning: operation on 'i' may be undefined

The source code is

for (i = entry; i != end; i = (++i) & lp->txRingMask) {

I agree with the compiler. Better code is

for (i = entry; i != end; i = (i + 1) & lp->txRingMask) {

Regards

David Binderman

_________________________________________________________________
Be the first to hear what's new at MSN - sign up to our free newsletters! 
http://www.msn.co.uk/newsletters


^ permalink raw reply	[flat|nested] 414+ messages in thread
* (no subject)
@ 2005-06-28  9:15 d binderman
  2005-06-28 11:00 ` Andrew Morton
  0 siblings, 1 reply; 414+ messages in thread
From: d binderman @ 2005-06-28  9:15 UTC (permalink / raw)
  To: linux-kernel

Hello there,

I just tried to compile the Linux Kernel version 2.6.11.12
with the most excellent Intel C compiler. It said

drivers/usb/host/ohci-hub.c(424): warning #175: subscript out of range
        desc->bitmap [2] = desc->bitmap [3] = 0xff;
                           ^

This is clearly broken code, since there are only up to 16 ports.

Suggest avoid trying to initialise bitmap[ 3].

Regards

David Binderman

_________________________________________________________________
It's fast, it's easy and it's free. Get MSN Messenger 7.0 today! 
http://messenger.msn.co.uk


^ permalink raw reply	[flat|nested] 414+ messages in thread
[parent not found: <360D47F92A8ACCH7@vger.kernel.org>]
* (no subject)
@ 2005-05-06 20:23 Edison Giovanny Mendoza
  2005-05-06 20:32 ` Alejandro Bonilla
  0 siblings, 1 reply; 414+ messages in thread
From: Edison Giovanny Mendoza @ 2005-05-06 20:23 UTC (permalink / raw)
  To: linux-kernel


SALUDOS;

FAVOR ENVIARME TODA LA INFORMACION QUE DISPONGAN DE LINUX LES CONFESARE QUE 
NO CONOSCO NADA .

MUCHAS  GRACIAS

AT.
EDISON MENDOZA
ECUADOR -QUITO

_________________________________________________________________
Charla con tus amigos en línea mediante MSN Messenger: 
http://messenger.latam.msn.com/


^ permalink raw reply	[flat|nested] 414+ messages in thread
* (no subject)
@ 2005-03-25  7:03 Søren Lott
  2005-03-25  7:18 ` Jeff Garzik
  0 siblings, 1 reply; 414+ messages in thread
From: Søren Lott @ 2005-03-25  7:03 UTC (permalink / raw)
  To: linux-kernel; +Cc: jgarzik

in the SATA kconfig menu, the help message from  
Intel PIIX/ICH SATA support says:

 CONFIG_SCSI_ATA_PIIX:

This option enables support for ICH5 Serial ATA.
 If PATA support was enabled previously, this enables
 support for select Intel PIIX/ICH PATA host controllers.

anyone care to clarify if this mean that having enabled:

CONFIG_IDE=y
CONFIG_BLK_DEV_IDE=y

i can use the PATA ports on a ICH5 controller through libata ?
if not, which is exactly the meaning of "If PATA support was enabled
previously" on this message ?

thanks.

-SL.

^ permalink raw reply	[flat|nested] 414+ messages in thread
* Re:
@ 2005-03-20  5:24 info
  0 siblings, 0 replies; 414+ messages in thread
From: info @ 2005-03-20  5:24 UTC (permalink / raw)
  To: linux-kernel

^[$B40A4L5NA3NDj!*!*!*^[(B
^[$B:#$^$G!"El5~8BDj$@$C$?%5%$%H$,^[(B
^[$B9%I>$K$D$-!"A49q3HBg!*!*:#$,%A%c%s%9$G$9!#^[(B
^[$B"(%3%3$KEPO?$7$F$k=w$N;R$OK\Ev$G$9!#^[(B
1.^[$B5U!{=u4uK>=w@-^[(B
2.^[$B#S#M4uK>=w@-^[(B
3.^[$B:#F|=P2q$$$?$$=w@-^[(B
4.^[$BITNQ4uK>=w@-^[(B
^[$B$J$I$N=w@-=P2q$$J|Bj^[(B

^[$BAa$/$7$J$$$H#S#O#L#D!!#O#U#T^[(B
http://loves.qsv20.com/



^ permalink raw reply	[flat|nested] 414+ messages in thread
* (no subject)
@ 2005-03-08 16:32 Peter W. Morreale
  2005-03-08 19:32 ` Ross Biro
  0 siblings, 1 reply; 414+ messages in thread
From: Peter W. Morreale @ 2005-03-08 16:32 UTC (permalink / raw)
  To: linux-kernel

In a driver I am reviewing I found the following locking constructs.
Notice how 'foo" is being called while we have suspended interrupts.

This seems wrong since we've mixed locking primitives.

Is it?

Thanks in advance.

-PWM

---------------------snip--------------------------------------
spin_lock_irqsave(global_lock, &flags);
....
foo()
{
    unsigned long lflags;

    spin_unlock(global_lock);
    ...
    {
        spin_lock_irqsave(global_lock, &lflags);
                .
                .
        spin_unlock_irqrestore(global_lock, &lflags);
    }

    spin_lock_irq(global_lock);
}

spin_unlock_irqrestore(global_lock, &flags);



^ permalink raw reply	[flat|nested] 414+ messages in thread
* (no subject)
@ 2005-03-05 10:11 Raffaele Ianniello
  2005-03-05 18:14 ` Randy.Dunlap
  0 siblings, 1 reply; 414+ messages in thread
From: Raffaele Ianniello @ 2005-03-05 10:11 UTC (permalink / raw)
  To: linux-kernel


I have a problem compiling a module that I am porting form 2.4 to 2.6 linux kernel.

Compiling with this Makefile:
 
DEBUG = y
 
KERNELDIR = /usr/src/linix.2.6.9
SUBDIR = $(KERNELDIR)/drivers/snoop
INCLUDEDIR = $(KERNELDIR)/include
 
obj-m := snoop.o
 
modules: $(MAKE) -C $(KERNELDIR) SUBDIR=$(SUBDIR) modules
 
clean:
        rm -f *.o
        rm -f *.ko

apperars some lines like:
***Warning: "snoop_ip_forward" [drivers/snoop/snoop] is COMMON symbol
***Warning: "snoop_ip_forward_finish" [drivers/snoop/snoop] is COMMON symbol
 
and I have insert in ip_forward.c some lines:
 
    extern int (* snoop_ip_forward_finish) (struct sk_buff *);

and this is in function ip_forward():
       if(snoop_ip_forward && (*snoop_ip_forward)(skb) == -6)
                goto drop;
 
then when I try to install the module it repyes with:
    insmod: error inserting 'snoop.ko': -1 Invalid module format

and in /var/log/message appears some lines line:
    kernel: snoop: Unknown symbol __floatsidf
    kernel: snoop: Unknown symbol __fixunsdfsi
    kernel: snoop: Unknown symbol __adddf3
    kernel: snoop: Unknown symbol __muldf3

I will be very pleased if you can help me in some way.
thank you for your time

regards,
Raffaele 


^ permalink raw reply	[flat|nested] 414+ messages in thread
* RE:
@ 2005-02-26 14:57 Yong Haynes
  0 siblings, 0 replies; 414+ messages in thread
From: Yong Haynes @ 2005-02-26 14:57 UTC (permalink / raw)
  To: linux-kernel

              





^ permalink raw reply	[flat|nested] 414+ messages in thread
* (no subject)
@ 2005-02-17 17:14 Deepti Patel
  2005-02-17 17:46 ` Matthias-Christian Ott
  0 siblings, 1 reply; 414+ messages in thread
From: Deepti Patel @ 2005-02-17 17:14 UTC (permalink / raw)
  To: linux-kernel; +Cc: pateldeepti

Hi 
I am getting an error while inserting an hello world program. 

[deepti@marieke deepti]$ /sbin/insmod hello-2.ko
insmod: error inserting 'hello-2.ko': -1 Operation not permitted

I haven't logged in as root. For inserting a module do I need to logged in as root?
I will really appretiate any suggestions.

Thanks in advance



-- 
_______________________________________________
Find what you are looking for with the Lycos Yellow Pages
http://r.lycos.com/r/yp_emailfooter/http://yellowpages.lycos.com/default.asp?SRC=lycos10


^ permalink raw reply	[flat|nested] 414+ messages in thread
* (no subject)
@ 2005-01-19 14:25 Gmail
  2005-01-19 15:22 ` Paolo Ornati
  0 siblings, 1 reply; 414+ messages in thread
From: Gmail @ 2005-01-19 14:25 UTC (permalink / raw)
  To: linux-kernel

--------------------------------------------------------------
 * Building module-init-tools...
./configure --prefix=/usr --host=i486-slackware-linux --mandir=//usr/share/man --infodir=//usr/share/info --datadir=//usr/share --sysconfdir=//etc --localstatedir=//var/lib --prefix=/ --enable-zlib
configure: WARNING: If you wanted to set the --build type, don't use --host.
    If a cross compiler is detected then cross compile mode will be used.
checking build system type... i586-pc-linux-gnu
checking host system type... i486-slackware-linux-gnu
checking target system type... i486-slackware-linux-gnu
checking for a BSD-compatible install... /usr/bin/ginstall -c
checking whether build environment is sane... yes
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking for i486-slackware-linux-strip... no
checking for strip... strip
checking for i486-slackware-linux-gcc... gcc
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ANSI C... none needed
checking for style of include used by make... GNU
checking dependency style of gcc... gcc3
configure: Adding gcc options: -O2 -mcpu=i686 -pipe -Wunused -Wall
configure: creating ./config.status
config.status: creating Makefile
config.status: executing depfiles commands
Makefile:385: *** missing separator.  Stop.

!!! ERROR: sys-apps/module-init-tools-3.0-r2 failed.
!!! Function src_compile, Line 1980, Exitcode 2
!!! emake module-init-tools failed
!!! If you need support, post the topmost build error, NOT this status message.

phases failed
-------------------------------------------------------------------

[1] When we reach the 'make' command.. it prints that error...
Makefile:385. I'm not familiar at all with this kind of stuff... So I
just CAN'T help myself! And that makes me nervous...

[2]
[3] module-init-tools
[4] Linux version 2.4.26 (root@tree) (gcc version 3.3.4) #6 Mon Jun 14 19:07:27 PDT 2004
[6] bash# make


^ permalink raw reply	[flat|nested] 414+ messages in thread
* (no subject)
@ 2004-11-08  7:39 Marcelo Tosatti
  2004-11-08 11:08 ` Paolo Ciarrocchi
  0 siblings, 1 reply; 414+ messages in thread
From: Marcelo Tosatti @ 2004-11-08  7:39 UTC (permalink / raw)
  To: linux-kernel


unsubscribe linux-kernel

^ permalink raw reply	[flat|nested] 414+ messages in thread
* (no subject)
@ 2004-09-19 12:29 plt
       [not found] ` <200409191508.33537.Norbert@edusupport.nl>
  0 siblings, 1 reply; 414+ messages in thread
From: plt @ 2004-09-19 12:29 UTC (permalink / raw)
  To: linux-kernel

Question: Are you guys going to work on please cleaning up some of the errors in
the code so we can get please get a more clean compile?



drivers/mtd/nftlmount.c:44: warning: unused variable `oob'

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.


^ permalink raw reply	[flat|nested] 414+ messages in thread
* (no subject)
@ 2004-06-27 14:18 Vinu Moses
  2004-06-27 20:14 ` Vinu Moses
  0 siblings, 1 reply; 414+ messages in thread
From: Vinu Moses @ 2004-06-27 14:18 UTC (permalink / raw)
  To: linux-kernel

unsubscribe linux-kernel

^ permalink raw reply	[flat|nested] 414+ messages in thread
* re:
@ 2004-03-17 22:03 Kendrick Logan
  0 siblings, 0 replies; 414+ messages in thread
From: Kendrick Logan @ 2004-03-17 22:03 UTC (permalink / raw)
  To: linux-kernel-owner; +Cc: linux-kernel, linux-msdos, linux-net, linux-scsi

[-- Attachment #1: Type: text/plain, Size: 1262 bytes --]

Paradise SEX Island Awaits! Tropical 1 week vacations where anything 
goes!


We have lots of WOMEN, SEX, ALCOHOL, ETC!

Every man's dream awaits on this island of pleasure.

Ever wonder what a Fantasy Sex Holiday would be like? 

If it was available at a reasonable cost.........would you go? 

Check out more information on our site & we can make your dream 
vacation a reality....


*All contact, reservations, billings, are strcitly confidential & are 
discussed directly with the client only.

**Group discounts are available. ie. Bachelor parties, etc.

MARCH/APRIL BONUS now available.

http://www.intimate-travelclub.com






















This communication is privileged and contains confidential information 
intended only for the person(s) to whom it is addressed.  Any 
unauthorized disclosure, copying, other distribution  of this 
communication or taking any action on its contents is strictly  prohibited. If you have 
received this message in error, please notify us immediately OR remove 
yourself from our list if there is no interest in regards to our 
services.

http://www.intimate-travelclub.com/remove/remove.html

8
kittenish ponce paso titanic decreeing duma conflagrate expansible carbide salk phone echidna excommunicate template 

^ permalink raw reply	[flat|nested] 414+ messages in thread
* (no subject)
@ 2004-03-07 20:08 Michael Frank
  2004-03-07 20:26 ` John Bradford
  0 siblings, 1 reply; 414+ messages in thread
From: Michael Frank @ 2004-03-07 20:08 UTC (permalink / raw)
  To: Marcelo Tosatti; +Cc: kernel mailing list

Marcelo,

Here is a patch to update 2.4 Codingstyle.

It is equivalent to the 2.6 version except for
Chapter 9 Configuration files which is unchanged

Please apply.

Regards
Michael

diff -uN linux-2.4.25-mhf184/Documentation/CodingStyle.mhf.orig linux-2.4.25-mhf184/Documentation/CodingStyle
--- linux-2.4.25-mhf184/Documentation/CodingStyle.mhf.orig	2004-02-27 12:30:50.000000000 +0800
+++ linux-2.4.25-mhf184/Documentation/CodingStyle	2004-03-08 04:04:11.000000000 +0800
@@ -1,42 +1,75 @@

-		Linux kernel coding style
+		Linux kernel coding style

  This is a short document describing the preferred coding style for the
  linux kernel.  Coding style is very personal, and I won't _force_ my
  views on anybody, but this is what goes for anything that I have to be
  able to maintain, and I'd prefer it for most other things too.  Please
-at least consider the points made here.
+at least consider the points made here.

  First off, I'd suggest printing out a copy of the GNU coding standards,
-and NOT read it.  Burn them, it's a great symbolic gesture.
+and NOT read it.  Burn them, it's a great symbolic gesture.

  Anyway, here goes:


  	 	Chapter 1: Indentation

-Tabs are 8 characters, and thus indentations are also 8 characters.
+Tabs are 8 characters, and thus indentations are also 8 characters.
  There are heretic movements that try to make indentations 4 (or even 2!)
  characters deep, and that is akin to trying to define the value of PI to
-be 3.
+be 3.

  Rationale: The whole idea behind indentation is to clearly define where
  a block of control starts and ends.  Especially when you've been looking
  at your screen for 20 straight hours, you'll find it a lot easier to see
-how the indentation works if you have large indentations.
+how the indentation works if you have large indentations.

  Now, some people will claim that having 8-character indentations makes
  the code move too far to the right, and makes it hard to read on a
  80-character terminal screen.  The answer to that is that if you need
  more than 3 levels of indentation, you're screwed anyway, and should fix
-your program.
+your program.

  In short, 8-char indents make things easier to read, and have the added
-benefit of warning you when you're nesting your functions too deep.
-Heed that warning.
+benefit of warning you when you're nesting your functions too deep.
+Heed that warning.

+Don't put multiple statements on a single line unless you have
+something to hide:

-		Chapter 2: Placing Braces
+	if (condition) do_this;
+	  do_something_everytime;
+
+Outside of comments, documentation and except in Kconfig, spaces are never
+used for indentation, and the above example is deliberately broken.
+
+Get a decent editor and don't leave whitespace at the end of lines.
+
+
+		Chapter 2: Breaking long lines and strings
+
+Coding style is all about readability and maintainability using commonly
+available tools.
+
+The limit on the length of lines is 80 columns and this is a hard limit.
+
+Statements longer than 80 columns will be broken into sensible chunks.
+Descendants are always substantially shorter than the parent and are placed
+substantially to the right. The same applies to function headers with a long
+argument list. Long strings are as well broken into shorter strings.
+
+void fun(int a, int b, int c)
+{
+	if (condition)
+		printk(KERN_WARNING "Warning this is a long printk with "
+						"3 parameters a: %u b: %u "
+						"c: %u \n", a, b, c);
+	else
+		next_statement;
+}
+
+		Chapter 3: Placing Braces

  The other issue that always comes up in C styling is the placement of
  braces.  Unlike the indent size, there are few technical reasons to
@@ -59,7 +92,7 @@
  Heretic people all over the world have claimed that this inconsistency
  is ...  well ...  inconsistent, but all right-thinking people know that
  (a) K&R are _right_ and (b) K&R are right.  Besides, functions are
-special anyway (you can't nest them in C).
+special anyway (you can't nest them in C).

  Note that the closing brace is empty on a line of its own, _except_ in
  the cases where it is followed by a continuation of the same statement,
@@ -79,60 +112,60 @@
  	} else {
  		....
  	}
-			
-Rationale: K&R.
+
+Rationale: K&R.

  Also, note that this brace-placement also minimizes the number of empty
  (or almost empty) lines, without any loss of readability.  Thus, as the
  supply of new-lines on your screen is not a renewable resource (think
  25-line terminal screens here), you have more empty lines to put
-comments on.
+comments on.


-		Chapter 3: Naming
+		Chapter 4: Naming

  C is a Spartan language, and so should your naming be.  Unlike Modula-2
  and Pascal programmers, C programmers do not use cute names like
  ThisVariableIsATemporaryCounter.  A C programmer would call that
  variable "tmp", which is much easier to write, and not the least more
-difficult to understand.
+difficult to understand.

  HOWEVER, while mixed-case names are frowned upon, descriptive names for
  global variables are a must.  To call a global function "foo" is a
-shooting offense.
+shooting offense.

  GLOBAL variables (to be used only if you _really_ need them) need to
  have descriptive names, as do global functions.  If you have a function
  that counts the number of active users, you should call that
-"count_active_users()" or similar, you should _not_ call it "cntusr()".
+"count_active_users()" or similar, you should _not_ call it "cntusr()".

  Encoding the type of a function into the name (so-called Hungarian
  notation) is brain damaged - the compiler knows the types anyway and can
  check those, and it only confuses the programmer.  No wonder MicroSoft
-makes buggy programs.
+makes buggy programs.

  LOCAL variable names should be short, and to the point.  If you have
-some random integer loop counter, it should probably be called "i".
+some random integer loop counter, it should probably be called "i".
  Calling it "loop_counter" is non-productive, if there is no chance of it
  being mis-understood.  Similarly, "tmp" can be just about any type of
-variable that is used to hold a temporary value.
+variable that is used to hold a temporary value.

  If you are afraid to mix up your local variable names, you have another
-problem, which is called the function-growth-hormone-imbalance syndrome.
-See next chapter.
+problem, which is called the function-growth-hormone-imbalance syndrome.
+See next chapter.

-		
-		Chapter 4: Functions
+
+		Chapter 5: Functions

  Functions should be short and sweet, and do just one thing.  They should
  fit on one or two screenfuls of text (the ISO/ANSI screen size is 80x24,
-as we all know), and do one thing and do that well.
+as we all know), and do one thing and do that well.

  The maximum length of a function is inversely proportional to the
  complexity and indentation level of that function.  So, if you have a
  conceptually simple function that is just one long (but simple)
  case-statement, where you have to do lots of small things for a lot of
-different cases, it's OK to have a longer function.
+different cases, it's OK to have a longer function.

  However, if you have a complex function, and you suspect that a
  less-than-gifted first-year high-school student might not even
@@ -140,41 +173,78 @@
  maximum limits all the more closely.  Use helper functions with
  descriptive names (you can ask the compiler to in-line them if you think
  it's performance-critical, and it will probably do a better job of it
-that you would have done).
+than you would have done).

  Another measure of the function is the number of local variables.  They
  shouldn't exceed 5-10, or you're doing something wrong.  Re-think the
  function, and split it into smaller pieces.  A human brain can
  generally easily keep track of about 7 different things, anything more
  and it gets confused.  You know you're brilliant, but maybe you'd like
-to understand what you did 2 weeks from now.
+to understand what you did 2 weeks from now.
+
+
+		Chapter 6: Centralized exiting of functions

+Albeit deprecated by some people, the equivalent of the goto statement is
+used frequently by compilers in form of the unconditional jump instruction.

-		Chapter 5: Commenting
+The goto statement comes in handy when a function exits from multiple
+locations and some common work such as cleanup has to be done.
+
+The rationale is:
+
+- unconditional statements are easier to understand and follow
+- nesting is reduced
+- errors by not updating individual exit points when making
+    modifications are prevented
+- saves the compiler work to optimize redundant code away ;)
+
+int fun(int )
+{
+	int result = 0;
+	char *buffer = kmalloc(SIZE);
+
+	if (buffer == NULL)
+		return -ENOMEM;
+
+	if (condition1) {
+		while (loop1) {
+			...
+		}
+		result = 1;
+		goto out;
+	}
+	...
+out:
+	kfree(buffer);
+	return result;
+}
+
+		Chapter 7: Commenting

  Comments are good, but there is also a danger of over-commenting.  NEVER
  try to explain HOW your code works in a comment: it's much better to
  write the code so that the _working_ is obvious, and it's a waste of
-time to explain badly written code.
+time to explain badly written code.

-Generally, you want your comments to tell WHAT your code does, not HOW.
+Generally, you want your comments to tell WHAT your code does, not HOW.
  Also, try to avoid putting comments inside a function body: if the
  function is so complex that you need to separately comment parts of it,
-you should probably go back to chapter 4 for a while.  You can make
+you should probably go back to chapter 5 for a while.  You can make
  small comments to note or warn about something particularly clever (or
  ugly), but try to avoid excess.  Instead, put the comments at the head
  of the function, telling people what it does, and possibly WHY it does
-it.
+it.


-		Chapter 6: You've made a mess of it
+		Chapter 8: You've made a mess of it

  That's OK, we all do.  You've probably been told by your long-time Unix
  user helper that "GNU emacs" automatically formats the C sources for
  you, and you've noticed that yes, it does do that, but the defaults it
  uses are less than desirable (in fact, they are worse than random
-typing - a infinite number of monkeys typing into GNU emacs would never
-make a good program).
+typing - an infinite number of monkeys typing into GNU emacs would never
+make a good program).

  So, you can either get rid of GNU emacs, or change it to use saner
  values.  To do the latter, you can stick the following in your .emacs file:
@@ -192,7 +262,7 @@
  to add

  (setq auto-mode-alist (cons '("/usr/src/linux.*/.*\\.[ch]$" . linux-c-mode)
-                       auto-mode-alist))
+			auto-mode-alist))

  to your .emacs file if you want to have linux-c-mode switched on
  automagically when you edit source files under /usr/src/linux.
@@ -200,19 +270,20 @@
  But even if you fail in getting emacs to do sane formatting, not
  everything is lost: use "indent".

-Now, again, GNU indent has the same brain dead settings that GNU emacs
-has, which is why you need to give it a few command line options.
+Now, again, GNU indent has the same brain-dead settings that GNU emacs
+has, which is why you need to give it a few command line options.
  However, that's not too bad, because even the makers of GNU indent
  recognize the authority of K&R (the GNU people aren't evil, they are
  just severely misguided in this matter), so you just give indent the
-options "-kr -i8" (stands for "K&R, 8 character indents").
+options "-kr -i8" (stands for "K&R, 8 character indents"), or use
+"scripts/Lindent", which indents in the latest style.

  "indent" has a lot of options, and especially when it comes to comment
-re-formatting you may want to take a look at the manual page.  But
-remember: "indent" is not a fix for bad programming.
+re-formatting you may want to take a look at the man page.  But
+remember: "indent" is not a fix for bad programming.


-		Chapter 7: Configuration-files
+		Chapter 9: Configuration-files

  For configuration options (arch/xxx/config.in, and all the Config.in files),
  somewhat different indentation is used.
@@ -235,20 +306,20 @@
  Experimental options should be denoted (EXPERIMENTAL).


-		Chapter 8: Data structures
+		Chapter 10: Data structures

  Data structures that have visibility outside the single-threaded
  environment they are created and destroyed in should always have
  reference counts.  In the kernel, garbage collection doesn't exist (and
  outside the kernel garbage collection is slow and inefficient), which
-means that you absolutely _have_ to reference count all your uses.
+means that you absolutely _have_ to reference count all your uses.

  Reference counting means that you can avoid locking, and allows multiple
  users to have access to the data structure in parallel - and not having
  to worry about the structure suddenly going away from under them just
-because they slept or did something else for a while.
+because they slept or did something else for a while.

-Note that locking is _not_ a replacement for reference counting.
+Note that locking is _not_ a replacement for reference counting.
  Locking is used to keep data structures coherent, while reference
  counting is a memory management technique.  Usually both are needed, and
  they are not to be confused with each other.
@@ -258,9 +329,99 @@
  the number of subclass users, and decrements the global count just once
  when the subclass count goes to zero.

-Examples of this kind of "multi-reference-counting" can be found in
+Examples of this kind of "multi-level-reference-counting" can be found in
  memory management ("struct mm_struct": mm_users and mm_count), and in
  filesystem code ("struct super_block": s_count and s_active).

  Remember: if another thread can find your data structure, and you don't
  have a reference count on it, you almost certainly have a bug.
+
+
+		Chapter 11: Macros, Enums, Inline functions and RTL
+
+Names of macros defining constants and labels in enums are capitalized.
+
+#define CONSTANT 0x12345
+
+Enums are preferred when defining several related constants.
+
+CAPITALIZED macro names are appreciated but macros resembling functions
+may be named in lower case.
+
+Generally, inline functions are preferable to macros resembling functions.
+
+Macros with multiple statements should be enclosed in a do - while block:
+
+#define macrofun(a,b,c) 			\
+	do {					\
+		if (a == 5)			\
+			do_this(b,c);		\
+	} while (0)
+
+Things to avoid when using macros:
+
+1) macros that affect control flow:
+
+#define FOO(x)					\
+	do {					\
+		if (blah(x) < 0)		\
+			return -EBUGGERED;	\
+	} while(0)
+
+is a _very_ bad idea.  It looks like a function call but exits the "calling"
+function; don't break the internal parsers of those who will read the code.
+
+2) macros that depend on having a local variable with a magic name:
+
+#define FOO(val) bar(index, val)
+
+might look like a good thing, but it's confusing as hell when one reads the
+code and it's prone to breakage from seemingly innocent changes.
+
+3) macros with arguments that are used as l-values: FOO(x) = y; will
+bite you if somebody e.g. turns FOO into an inline function.
+
+4) forgetting about precedence: macros defining constants using expressions
+must enclose the expression in parentheses. Beware of similar issues with
+macros using parameters.
+
+#define CONSTANT 0x4000
+#define CONSTEXP (CONSTANT | 3)
+
+The cpp manual deals with macros exhaustively. The gcc internals manual also
+covers RTL which is used frequently with assembly language in the kernel.
+
+
+		Chapter 12: Printing kernel messages
+
+Kernel developers like to be seen as literate. Do mind the spelling
+of kernel messages to make a good impression. Do not use crippled
+words like "dont" and use "do not" or "don't" instead.
+
+Kernel messages do not have to be terminated with a period.
+
+Printing numbers in parentheses (%d) adds no value and should be avoided.
+
+
+		Chapter 13: References
+
+The C Programming Language, Second Edition
+by Brian W. Kernighan and Dennis M. Ritchie.
+Prentice Hall, Inc., 1988.
+ISBN 0-13-110362-8 (paperback), 0-13-110370-9 (hardback).
+URL: http://cm.bell-labs.com/cm/cs/cbook/
+
+The Practice of Programming
+by Brian W. Kernighan and Rob Pike.
+Addison-Wesley, Inc., 1999.
+ISBN 0-201-61586-X.
+URL: http://cm.bell-labs.com/cm/cs/tpop/
+
+GNU manuals - where in compliance with K&R and this text - for cpp, gcc,
+gcc internals and indent, all available from http://www.gnu.org
+
+WG14 is the international standardization working group for the programming
+language C, URL: http://std.dkuug.dk/JTC1/SC22/WG14/
+
+--
+Last updated on 16 February 2004 by a community effort on LKML.


^ permalink raw reply	[flat|nested] 414+ messages in thread
* (no subject)
@ 2004-02-22 17:51 redzic fadil
  2004-02-22 18:48 ` Larry Reaves
  0 siblings, 1 reply; 414+ messages in thread
From: redzic fadil @ 2004-02-22 17:51 UTC (permalink / raw)
  To: linux-kernel

hello


I hope I don't disturb,


I have tried to compile the hello.c module under kernel 2.6.3.
And I'd like to insert the hello.o module in the kernel.
But this doesn't work with kernel 2.6.3 .

I have compiled this module with kernel 2.4.* and it is well.

Also I cannot include the header file module.h, because I get error 
messages.

my module:
#include <linux/kernel.h>
#include <linux/module.h>
#include <linux/init.h>


int initial_module (void)
{
	printk("\ninitial module\n");
	return (0);
}

void delete_module (void)
{
	printk("\ndelete module\n");
}

module_init(initial_module);
module_exit(delete_module);


my Makefile:
CC=gcc
CFLAGS=-isystem /lib/modules/`uname -r`/build/include -O2 -D__KERNEL__ 
-DMODULE
all: hello.o

If you have any idea please send an E-Mail:  redzic_fadil@hotmail.com

thanks

_________________________________________________________________
Die ultimative Fan-Seite für den MSN Messenger http://www.ilovemessenger.de 
Emoticons und Hintergründe kostenlos downloaden!


^ permalink raw reply	[flat|nested] 414+ messages in thread
* Re:
@ 2004-02-14 23:17 Alexandr Chernyy
  0 siblings, 0 replies; 414+ messages in thread
From: Alexandr Chernyy @ 2004-02-14 23:17 UTC (permalink / raw)
  To: linux-kernel

On Monday 09 February 2004 22:05, Alexandr Chernyy wrote:

 >> Hello All! Can you help me! I write module for kernel 2.4.22 and have
 >> some problems! I need to read some information form file, create
 >> directory and etc. (Did kerlen have some stdio.h like function - fopen,
 >> fgets, fclose......)!!! Please help me.


 > what you are looking for is not usually needed by 'normal' kernel 
modules.
 > could you please be more specific on what is exactly your porpouse?

 > alessandro

for example i need to create directory in all mounting devices when 
module load!!!
and read some informations form /proc/mounts

WBR, Alexandr Chernyy



^ permalink raw reply	[flat|nested] 414+ messages in thread
[parent not found: <7A25937D23A1E64C8E93CB4A50509C2A0310F099@stca204a.bus.sc.rolm.com>]
* (no subject)
@ 2003-12-11 23:37 Hettinger Tamas
  2003-12-12  1:29 ` Jonathan Corbet
  0 siblings, 1 reply; 414+ messages in thread
From: Hettinger Tamas @ 2003-12-11 23:37 UTC (permalink / raw)
  To: linux-kernel

Hi everybody !

I've been developing a kernel module and I needed some timer functions. I
found init_timer() add_timer() del_timer() etc... but I would ask some
questions about them.

1) When I set a timer, it is added to a timer_list chain with add_timer().
If the time is up and the scheduled function is called, should I remove the
timer_list struct from the chain via del_timer() ? Or is it removed
automatically ?

2) How can a module safely removed if it has some running timers ? I have to
call del_timer() in cleanup_module() for each running timer ? And what's the
purpose of the timer_pending function ?

thanks


^ permalink raw reply	[flat|nested] 414+ messages in thread
* (no subject)
@ 2003-12-05 17:36 gmack
  2003-12-05 23:16 ` Oliver Hunt
  0 siblings, 1 reply; 414+ messages in thread
From: gmack @ 2003-12-05 17:36 UTC (permalink / raw)


>From gmack@innerfire.net  Fri Dec  5 12:36:11 2003
Received: from localhost (sendmail-bs@127.0.0.1)
  by localhost with SMTP; 5 Dec 2003 17:36:11 -0000
Date: Fri, 5 Dec 2003 12:36:11 -0500 (EST)
From: Gerhard Mack <gmack@innerfire.net>
To: Linus Torvalds <torvalds@osdl.org>
cc: David Schwartz <davids@webmaster.com>, Valdis.Kletnieks@vt.edu, 
    Peter Chubb <peter@chubb.wattle.id.au>, linux-kernel@vger.kernel.org
Subject: RE: Linux GPL and binary module exception clause? 
In-Reply-To: <Pine.LNX.4.58.0312042245350.9125@home.osdl.org>
Message-ID: <Pine.LNX.4.58.0312051232530.16547@innerfire.net>
References: <MDEHLPKNGKAHNMBLJOLKMEIDIHAA.davids@webmaster.com>
 <Pine.LNX.4.58.0312042245350.9125@home.osdl.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Status: No, hits=-104.5 required=4.0 tests=IN_REP_TO,SUBJ_ENDS_IN_Q_MARK,USER_IN_WHITELIST version=2.20
X-Spam-Level: 

Those views are scary when you consider that webmaster Inc sells closed
source software that works exactly like IRC (wich is GPL)

On Thu, 4 Dec 2003, Linus Torvalds wrote:

> Date: Thu, 4 Dec 2003 22:58:09 -0800 (PST)
> From: Linus Torvalds <torvalds@osdl.org>
> To: David Schwartz <davids@webmaster.com>
> Cc: Valdis.Kletnieks@vt.edu, Peter Chubb <peter@chubb.wattle.id.au>,
>      linux-kernel@vger.kernel.org
> Subject: RE: Linux GPL and binary module exception clause?
>
>
>
> On Thu, 4 Dec 2003, David Schwartz wrote:
> >
> > The GPL gives you the unrestricted right to *use* the original work.
> > This implicitly includes the right to peform any step necessary to use
> > the work.
>
> No it doesn't.
>
> Your logic is fundamentally flawed, and/or your reading skills are
> deficient.
>
> The GPL expressly states that the license does not restrict the act of
> "running the Program" in any way, and yes, in that sense you may "use" the
> program in whatever way you want.
>
> But that "use" is clearly limited to running the resultant program. It
> very much does NOT say that you can "use the header files in any way you
> want, including building non-GPL'd programs with them".
>
> In fact, it very much says the reverse. If you use the source code to
> build a new program, the GPL _explicitly_ says that that new program has
> to be GPL'd too.
>
> > Please tell me how you use a kernel header file, other than by including
> > it in a code file, compiling that code file, and executing the result.
>
> You are a weasel, and you are trying to make the world look the way you
> want it to, rather than the way it _is_.
>
> You use the word "use" in a sense that is not compatible with the GPL. You
> claim that the GPL says that you can "use the program any way you want",
> but that is simply not accurate or even _close_ to accurate. Go back and
> read the GPL again. It says:
>
> 	"The act of running the Program is not restricted"
>
> and it very much does NOT say
>
> 	"The act of using parts of the source code of the Program is not
> 	 restricted"
>
> In short: you do _NOT_ have the right to use a kernel header file (or any
> other part of the kernel sources), unless that use results in a GPL'd
> program.
>
> What you _do_ have the right is to _run_ the kernel any way you please
> (this is the part you would like to redefine as "use the source code",
> but that definition simply isn't allowed by the license, however much you
> protest to the contrary).
>
> So you can run the kernel and create non-GPL'd programs while running it
> to your hearts content. You can use it to control a nuclear submarine, and
> that's totally outside the scope of the license (but if you do, please
> note that the license does not imply any kind of warranty or similar).
>
> BUT YOU CAN NOT USE THE KERNEL HEADER FILES TO CREATE NON-GPL'D BINARIES.
>
> Comprende?
>
> 		Linus
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

--
Gerhard Mack

gmack@innerfire.net

<>< As a computer I find your faith in technology amusing.

^ permalink raw reply	[flat|nested] 414+ messages in thread
* (no subject)
@ 2003-12-03 15:08 Bloch, Jack
  2003-12-04  4:56 ` Raj
  0 siblings, 1 reply; 414+ messages in thread
From: Bloch, Jack @ 2003-12-03 15:08 UTC (permalink / raw)
  To: linux-kernel

I try to open a non-existan device driver node file. The Kernel returns a
value of -1 (expected). However, when I read the value of errno it contains
a value of 29. A call to the perror functrion does print out the correct
error message (a value of 2). Why does this happen?

Jack Bloch 
Siemens ICN
phone                (561) 923-6550
e-mail                jack.bloch@icn.siemens.com


^ permalink raw reply	[flat|nested] 414+ messages in thread
* (no subject)
@ 2003-09-10  2:20 John Yau
  2003-09-10  2:31 ` Nick Piggin
  0 siblings, 1 reply; 414+ messages in thread
From: John Yau @ 2003-09-10  2:20 UTC (permalink / raw)
  To: piggin; +Cc: linux-kernel

>Your mechanism is basically "backboost". Its how you get X to keep a
>high piroirity, but quite unpredictable. Giving a boost to a process
>holding a semaphore is an interesting idea, but it doesn't address the
>X problem.

Hmm...I'm actually curious why you called it "backboosting".  In academia
this approach first described in the paper here:

L. Sha, R. Rajkumar, and J. P. Lehoczky. Priority Inheritance Protocols: An
Approach to Real-Time Synchronization. In IEEE Transactions on Computers,
vol. 39, pp. 1175-1185, Sep. 1990.

is referred to as priority inheritance.  Is there significant difference
between your implementation and priority inheritance schemes implemented in
other OSes?  If so, why backboosting?

I was under the impression that pipes and IPC in general are synchronized
using some sort of semaphores/mutex...or does Linux use a different
mechanism for IPC and does away with user space synchronization all together
(e.g. flip-flop buffers with the kernel arbitrating all contention)?  IIRC
processes don't write to X directly and has to send data to X via IPC.  If
some futex derivative is used to synchronize the producers with X, then
making priority inheritable futexes would solve the problem.

>The scheduler in Linus' tree is basically obsolete now, so there isn't
>any point testing it really. Test Con's or my patches, and let us know
>if you're still having problems with sir dumps-a-lot.

Okay enough said, you and Con should get your patches merged into that tree
ASAP if they're ready.


John Yau

^ permalink raw reply	[flat|nested] 414+ messages in thread
* (no subject)
@ 2003-08-25 13:53 Marcelo Tosatti
  2003-08-25 14:12 ` Nick Piggin
  0 siblings, 1 reply; 414+ messages in thread
From: Marcelo Tosatti @ 2003-08-25 13:53 UTC (permalink / raw)
  To: Nick Piggin; +Cc: lkml


>
>
> Matthias Andree wrote:
>
> >On Mon, 25 Aug 2003, Marcelo Tosatti wrote:
> >
> >
> >>- 2.4.22-rc4 was released as 2.4.22 with no changes.
> >>
> >
> >What are the plans for 2.4.23? XFS merge perhaps <hint>?
> >
>
> Maybe some of Andrea's VM stuff?

Definately. Thats the first thing I'm going to do after looking through
"2.4.23-pre-patches" folder.

^ permalink raw reply	[flat|nested] 414+ messages in thread
* (no subject)
@ 2003-08-12 13:55 Catalin BOIE
  2003-08-12 17:05 ` Ian Hastie
  0 siblings, 1 reply; 414+ messages in thread
From: Catalin BOIE @ 2003-08-12 13:55 UTC (permalink / raw)
  To: linux-kernel

Hello!

"cat drivers/built-in.o > /dev/null" gives me i/o error.

Can I suspect a bad sector?
I use reiserfs.

Thanks!

---
Catalin(ux) BOIE
catab@deuroconsult.ro

^ permalink raw reply	[flat|nested] 414+ messages in thread
* (no subject)
@ 2003-07-16 18:36 Sir Ace
  2003-07-16 23:10 ` jiho
  0 siblings, 1 reply; 414+ messages in thread
From: Sir Ace @ 2003-07-16 18:36 UTC (permalink / raw)
  To: linux-kernel

unsubscribe linux-kernel

^ permalink raw reply	[flat|nested] 414+ messages in thread
* (no subject)
@ 2003-06-30  3:16 usenet
  2003-06-30  8:09 ` Bruce Harada
  0 siblings, 1 reply; 414+ messages in thread
From: usenet @ 2003-06-30  3:16 UTC (permalink / raw)
  To: linux-kernel



^ permalink raw reply	[flat|nested] 414+ messages in thread
* (no subject)
@ 2003-06-03 23:51 Justin T. Gibbs
  2003-06-03 23:58 ` Marc-Christian Petersen
  0 siblings, 1 reply; 414+ messages in thread
From: Justin T. Gibbs @ 2003-06-03 23:51 UTC (permalink / raw)
  To: linux-scsi, linux-kernel; +Cc: Linus Torvalds, Alan Cox, Marcelo Tosatti

Folks,

I've just uploaded version 1.3.10 of the aic79xx driver and version 
6.2.36 of the aic7xxx driver.  Both are available for 2.4.X and
2.5.X kernels in either bk send format or as a tarball from here:
 
http://people.FreeBSD.org/~gibbs/linux/SRC/

The change sets relative to the 2.5.X tree are:

ChangeSet@1.1275, 2003-06-03 17:35:01-06:00, gibbs@overdrive.btc.adaptec.com
  Update Aic79xx Readme

ChangeSet@1.1274, 2003-06-03 17:22:05-06:00, gibbs@overdrive.btc.adaptec.com
  Aic7xxx Driver Update
   o Bump version number to 6.2.36
   o Document recent aic7xxx driver releases

ChangeSet@1.1273, 2003-06-03 17:20:14-06:00, gibbs@overdrive.btc.adaptec.com
  Aic79xx Driver Update
   o Bump driver version to 1.3.10
   o Document recent releases in driver readme.

ChangeSet@1.1272, 2003-05-31 21:12:09-06:00, gibbs@overdrive.btc.adaptec.com
  Aic7xxx and Aic79xx Driver Update
   o Work around negotiation firmware bug in the Quantum Atlas 10K
   o Clear stale PCI errors in our register mapping test to avoid
     false positives from rouge accesses to our registers that occur
     prior to our driver attach.

ChangeSet@1.1271, 2003-05-31 18:34:01-06:00, gibbs@overdrive.btc.adaptec.com
  Aic79xx Driver Update
   o Implement suspend and resume

ChangeSet@1.1270, 2003-05-31 18:32:36-06:00, gibbs@overdrive.btc.adaptec.com
  Aic7xxx Driver Update
   o Fix some suspend and resume bugs

ChangeSet@1.1269, 2003-05-31 18:27:09-06:00, gibbs@overdrive.btc.adaptec.com
  Aic7xxx Driver Update
   o Correct the type of the DV settings array.

ChangeSet@1.1268, 2003-05-31 18:25:28-06:00, gibbs@overdrive.btc.adaptec.com
  Aic7xxx and Aic79xx driver Update
   o Remove unecessary and incorrect use of ~0 as a mask.

ChangeSet@1.1267, 2003-05-30 13:50:00-06:00, gibbs@overdrive.btc.adaptec.com
  Aic7xxx and Aic79xx Driver Update
   o Adapt to 2.5.X SCSI proc interface change while maitaining
     compatibility with earlier kernels.

ChangeSet@1.1266, 2003-05-30 11:01:02-06:00, gibbs@overdrive.btc.adaptec.com
  Merge http://linux.bkbits.net/linux-2.5
  into overdrive.btc.adaptec.com:/usr/home/gibbs/bk/linux-2.5

ChangeSet@1.1215.4.6, 2003-05-30 10:50:17-06:00, gibbs@overdrive.btc.adaptec.com
  Aic7xxx Driver Update
   o Bring in aic7xxx_reg_print.c update that was missed the
     last time the firmware was regenerated.  The old file worked
     fine, so this is mostly a cosmetic change.

ChangeSet@1.1215.4.5, 2003-05-30 10:48:31-06:00, gibbs@overdrive.btc.adaptec.com
  Aic79xx Driver Update
   o Correct non-zero lun output on post Rev A4 hardware
     in packetized mode.

ChangeSet@1.1215.4.4, 2003-05-30 10:46:03-06:00, gibbs@overdrive.btc.adaptec.com
  Aic79xx Driver Update
   o Return to using 16byte alignment for th SCB_TAG field in our SCB.
     The hardware seems to corrupt SCBs on some PCI platforms with the
     tag field in its old location.

ChangeSet@1.1215.4.3, 2003-05-30 10:43:20-06:00, gibbs@overdrive.btc.adaptec.com
  Aic7xxx Driver Update
   o Adopt 2.5.X EISA framework for probing aic7770 controllers

ChangeSet@1.1215.4.2, 2003-05-30 10:31:04-06:00, gibbs@overdrive.btc.adaptec.com
  Aic7xxx Driver Update
   o Correct card identifcation string for the 2920C



^ permalink raw reply	[flat|nested] 414+ messages in thread
* (no subject)
@ 2003-04-30 21:39 Mauricio Oliveira Carneiro
  2003-05-01  0:03 ` Eyal Lebedinsky
  0 siblings, 1 reply; 414+ messages in thread
From: Mauricio Oliveira Carneiro @ 2003-04-30 21:39 UTC (permalink / raw)
  To: linux-kernel

Hi everyone,

I'm almost hanging myself.. it's been a week trying without success :-( 
Maybe someone here could help me out. Sorry for the disturbance ! 

I have bought a USB FLASH MEMORY device from Kmit Co. The model is : "Unity 
ITS". I bought it from FRY's Electronics in Palo Alto, CA (USA)
 
It works perfectly with windows, but i'm having problems with linux 2.4.20- 
9 kernel.
 
It detects the existance of the USB FLASH MEMORY device, as of my 
/proc/bus/usb/device file says :
 
C:* #Ifs= 2 Cfg#= 1 Atr=a0 MxPwr= 98mA
I:  If#= 0 Alt= 0 #EPs= 1 Cls=03(HID  ) Sub=01 Prot=01 Driver=hid
E:  Ad=81(I) Atr=03(Int.) MxPS=   8 Ivl=10ms
I:  If#= 1 Alt= 0 #EPs= 1 Cls=03(HID  ) Sub=01 Prot=02 Driver=hid
E:  Ad=82(I) Atr=03(Int.) MxPS=   8 Ivl=10ms
T:  Bus=02 Lev=01 Prnt=01 Port=01 Cnt=02 Dev#=  4 Spd=12  MxCh= 0
D:  Ver= 1.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=16 #Cfgs=  1
P:  Vendor=09a6 ProdID=8001 Rev= 1.00
S:  Manufacturer=KMIT CO.,LTD
S:  Product=KM USB Removable Disk
S:  SerialNumber=20021226113657-00
 
 
At the /proc/scsi/usb-storage-0/0 file I get :
 
   Host scsi0: usb-storage
       Vendor: KMIT CO.,LTD
      Product: KM USB Removable Disk
Serial Number: 20021226113657-00
     Protocol: 8070i
    Transport: Bulk
         GUID: 09a68001002122fffffff600
     Attached: Yes
 
 
In /etc/mtab :
 
usbdevfs on /proc/bus/usb type usbdevfs (rw)
 


But I can't see it mounted anywhere in my system, nor can I mount it by 
hand since I don't know the device filename (/dev/?) .
 
 
I believe it works the same way for every flash memory drive.

if someone have already suffered of the same cause, I thank for the help :)
 
Mauricio Oliveira Carneiro
 

^ permalink raw reply	[flat|nested] 414+ messages in thread
[parent not found: <001e01c2d9ef$01cdc970$0200a8c0@wsl3>]
* Re:
@ 2003-02-08 10:40 Manfred Spraul
  0 siblings, 0 replies; 414+ messages in thread
From: Manfred Spraul @ 2003-02-08 10:40 UTC (permalink / raw)
  To: Jun Sun; +Cc: linux-kernel

Jun wrote:

>cpu B:
>        get the ipi and (WITHOUT CHECKING cpu_vm_mask again)
>        go ahead doing tlb flushing.
>
>I am not sure if any disastrous result will happen, but apparently
>an unintended flush has happened.
>
Yes, that's possible. It should be rare (the windows is a few 
instructions long), and on i386 it doesn't hurt.

>In MIPS such a hole could
>cause two processes using the same TLB entries which yields all kinds
>of interesting crashes.
>
What is your problem? Do your mips cpus have mmu contexts (the ability 
to store tlb entries from multiple processes), and you load tlb entries 
with the wrong context id?
The i386 implementation knows that i386 cpus don't support mmu contexts, 
i.e. the whole tlb is flushed during process switches.

--
    Manfred



^ permalink raw reply	[flat|nested] 414+ messages in thread
* (no subject)
@ 2003-01-12 13:28 Philip K.F. Hölzenspies
  2003-01-12 17:57 ` Shawn Starr
  0 siblings, 1 reply; 414+ messages in thread
From: Philip K.F. Hölzenspies @ 2003-01-12 13:28 UTC (permalink / raw)
  To: linux-kernel
  Cc: 'Pete Zaitcev', 'Shawn Starr',
	'Bayard R. Coolidge'

I do have the following line in my fstab file (Bayard):

none  /proc/bus/usb  usbfs  defaults 0 0

I believe usbdevfs is deprecated (although - should I use it when my
hosthub is picked up by the OHCI driver in stead of the EHCI driver?).

My full dmesg is attached below (Pete), I'ld say the relevant section
is:

usb.c: registered new driver usbdevfs
usb.c: registered new driver hub
PCI: Enabling device 02:08.2 (0014 -> 0016)
PCI: No IRQ known for interrupt pin C of device 02:08.2. Probably buggy
MP table.
hcd.c: Found HC with no IRQ.  Check BIOS/PCI 02:08.2 setup!
uhci.c: USB Universal Host Controller Interface driver v1.1
PCI: Enabling device 02:08.0 (0014 -> 0016)
PCI: No IRQ known for interrupt pin A of device 02:08.0. Probably buggy
MP table.
usb-ohci.c: found OHCI device with no IRQ assigned. check BIOS settings!
PCI: Enabling device 02:08.1 (0014 -> 0016)
PCI: No IRQ known for interrupt pin B of device 02:08.1. Probably buggy
MP table.
usb-ohci.c: found OHCI device with no IRQ assigned. check BIOS settings!
usb.c: registered new driver hiddev
usb.c: registered new driver hid
hid-core.c: v1.8.1 Andreas Gal, Vojtech Pavlik <vojtech@suse.cz>
hid-core.c: USB HID support drivers
usb.c: registered new driver usblp
printer.c: v0.11: USB Printer Device Class driver
Initializing USB Mass Storage driver...
usb.c: registered new driver usb-storage
USB Mass Storage support registered.

Does anybody else with the A7M266-D have that "Probably buggy MP table."

For the OHCI 'found device with no IRQ assigned' I don't really get it.
I have all my PCI slots set to auto assign IRQ and I didn't reserve any
IRQ for Legacy Devices, so that shouldn't be the problem.

> I have this board, but the problem is the newer A7M266-D boards have
the USB
> 1.x pins removed.
(Shawn)

I don't know what would be considered a "newer" board, but mine is a 
03/07/2002-ASUS-A7M266-D

B.T.W.
I use BIOS rev. 1005.

Regards,

Philip

P.S.
Would configuring the kernel with >1GB mem support remove that
" Warning only 896MB will be used." from my dmesg?



Linux version 2.4.20 (root@tomwaits) (gcc version 3.2) #1 SMP Sat Jan 11
18:46:51 CET 2003
BIOS-provided physical RAM map:
 BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
 BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
 BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
 BIOS-e820: 0000000000100000 - 000000003ffec000 (usable)
 BIOS-e820: 000000003ffec000 - 000000003ffef000 (ACPI data)
 BIOS-e820: 000000003ffef000 - 000000003ffff000 (reserved)
 BIOS-e820: 000000003ffff000 - 0000000040000000 (ACPI NVS)
 BIOS-e820: 00000000fec00000 - 00000000fec01000 (reserved)
 BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved)
 BIOS-e820: 00000000ffff0000 - 0000000100000000 (reserved)
Warning only 896MB will be used.
Use a HIGHMEM enabled kernel.
896MB LOWMEM available.
found SMP MP-table at 000f6d10
hm, page 000f6000 reserved twice.
hm, page 000f7000 reserved twice.
hm, page 000f6000 reserved twice.
hm, page 000f7000 reserved twice.
On node 0 totalpages: 229376
zone(0): 4096 pages.
zone(1): 225280 pages.
zone(2): 0 pages.
Intel MultiProcessor Specification v1.4
    Virtual Wire compatibility mode.
OEM ID: ASUS     Product ID: PROD00000000 APIC at: 0xFEE00000
Processor #0 Pentium(tm) Pro APIC version 16
Processor #1 Pentium(tm) Pro APIC version 16
I/O APIC #2 Version 17 at 0xFEC00000.
Processors: 2
Kernel command line: BOOT_IMAGE=lfs ro root=305
Initializing CPU#0
Detected 1533.431 MHz processor.
Console: colour VGA+ 80x25
Calibrating delay loop... 3060.53 BogoMIPS
Memory: 904324k/917504k available (1707k kernel code, 12792k reserved,
604k data, 124k init, 0k highmem)
Dentry cache hash table entries: 131072 (order: 8, 1048576 bytes)
Inode cache hash table entries: 65536 (order: 7, 524288 bytes)
Mount-cache hash table entries: 16384 (order: 5, 131072 bytes)
Buffer-cache hash table entries: 65536 (order: 6, 262144 bytes)
Page-cache hash table entries: 262144 (order: 8, 1048576 bytes)
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
CPU: L2 Cache: 256K (64 bytes/line)
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
CPU:     After generic, caps: 0383fbff c1cbfbff 00000000 00000000
CPU:             Common caps: 0383fbff c1cbfbff 00000000 00000000
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Checking 'hlt' instruction... OK.
POSIX conformance testing by UNIFIX
mtrr: v1.40 (20010327) Richard Gooch (rgooch@atnf.csiro.au)
mtrr: detected mtrr type: Intel
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
CPU: L2 Cache: 256K (64 bytes/line)
Intel machine check reporting enabled on CPU#0.
CPU:     After generic, caps: 0383fbff c1cbfbff 00000000 00000000
CPU:             Common caps: 0383fbff c1cbfbff 00000000 00000000
CPU0: AMD Athlon(TM) MP 1800+ stepping 02
per-CPU timeslice cutoff: 731.39 usecs.
enabled ExtINT on CPU#0
ESR value before enabling vector: 00000000
ESR value after enabling vector: 00000000
Booting processor 1/1 eip 2000
Initializing CPU#1
masked ExtINT on CPU#1
ESR value before enabling vector: 00000000
ESR value after enabling vector: 00000000
Calibrating delay loop... 3060.53 BogoMIPS
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
CPU: L2 Cache: 256K (64 bytes/line)
Intel machine check reporting enabled on CPU#1.
CPU:     After generic, caps: 0383fbff c1cbfbff 00000000 00000000
CPU:             Common caps: 0383fbff c1cbfbff 00000000 00000000
CPU1: AMD Athlon(TM) MP 1800+ stepping 02
Total of 2 processors activated (6121.06 BogoMIPS).
ENABLING IO-APIC IRQs
Setting 2 in the phys_id_present_map
...changing IO-APIC physical APIC ID to 2 ... ok.
init IO_APIC IRQs
 IO-APIC (apicid-pin) 2-0, 2-5, 2-9, 2-10, 2-11, 2-17, 2-20, 2-21, 2-22,
2-23 not connected.
..TIMER: vector=0x31 pin1=2 pin2=0
number of MP IRQ sources: 16.
number of IO-APIC #2 registers: 24.
testing the IO APIC.......................

IO APIC #2......
.... register #00: 02000000
.......    : physical APIC id: 02
.... register #01: 00170011
.......     : max redirection entries: 0017
.......     : PRQ implemented: 0
.......     : IO APIC version: 0011
.... register #02: 00000000
.......     : arbitration: 00
.... IRQ redirection table:
 NR Log Phy Mask Trig IRR Pol Stat Dest Deli Vect:   
 00 000 00  1    0    0   0   0    0    0    00
 01 003 03  0    0    0   0   0    1    1    39
 02 003 03  0    0    0   0   0    1    1    31
 03 003 03  0    0    0   0   0    1    1    41
 04 003 03  0    0    0   0   0    1    1    49
 05 000 00  1    0    0   0   0    0    0    00
 06 003 03  0    0    0   0   0    1    1    51
 07 003 03  0    0    0   0   0    1    1    59
 08 003 03  0    0    0   0   0    1    1    61
 09 000 00  1    0    0   0   0    0    0    00
 0a 000 00  1    0    0   0   0    0    0    00
 0b 000 00  1    0    0   0   0    0    0    00
 0c 003 03  0    0    0   0   0    1    1    69
 0d 003 03  0    0    0   0   0    1    1    71
 0e 003 03  0    0    0   0   0    1    1    79
 0f 003 03  0    0    0   0   0    1    1    81
 10 003 03  1    1    0   1   0    1    1    89
 11 000 00  1    0    0   0   0    0    0    00
 12 003 03  1    1    0   1   0    1    1    91
 13 003 03  1    1    0   1   0    1    1    99
 14 000 00  1    0    0   0   0    0    0    00
 15 000 00  1    0    0   0   0    0    0    00
 16 000 00  1    0    0   0   0    0    0    00
 17 000 00  1    0    0   0   0    0    0    00
IRQ to pin mappings:
IRQ0 -> 0:2
IRQ1 -> 0:1
IRQ3 -> 0:3
IRQ4 -> 0:4
IRQ6 -> 0:6
IRQ7 -> 0:7
IRQ8 -> 0:8
IRQ12 -> 0:12
IRQ13 -> 0:13
IRQ14 -> 0:14
IRQ15 -> 0:15
IRQ16 -> 0:16
IRQ18 -> 0:18
IRQ19 -> 0:19
.................................... done.
Using local APIC timer interrupts.
calibrating APIC timer ...
..... CPU clock speed is 1533.4929 MHz.
..... host bus clock speed is 266.6942 MHz.
cpu: 0, clocks: 2666942, slice: 888980
CPU0<T0:2666928,T1:1777936,D:12,S:888980,C:2666942>
cpu: 1, clocks: 2666942, slice: 888980
CPU1<T0:2666928,T1:888960,D:8,S:888980,C:2666942>
checking TSC synchronization across CPUs: passed.
Waiting on wait_init_idle (map = 0x2)
All processors have done init_idle
mtrr: your CPUs had inconsistent fixed MTRR settings
mtrr: probably your BIOS does not setup all CPUs
PCI: PCI BIOS revision 2.10 entry at 0xf0de0, last bus=2
PCI: Using configuration type 1
PCI: Probing PCI hardware
PCI: Using IRQ router AMD768 [1022/7443] at 00:07.3
PCI->APIC IRQ transform: (B1,I5,P0) -> 16
PCI->APIC IRQ transform: (B2,I5,P0) -> 18
BIOS failed to enable PCI standards compliance, fixing this error.
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Initializing RT netlink socket
Starting kswapd
Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
NTFS driver v1.1.22 [Flags: R/O]
pty: 256 Unix98 ptys configured
Serial driver version 5.05c (2001-07-08) with MANY_PORTS SHARE_IRQ
SERIAL_PCI enabled
ttyS00 at 0x03f8 (irq = 4) is a 16550A
ttyS01 at 0x02f8 (irq = 3) is a 16550A
amd768_rng: AMD768 system management I/O registers at 0xE400.
amd768_rng hardware driver 0.1.0 loaded
Uniform Multi-Platform E-IDE driver Revision: 6.31
ide: Assuming 33MHz system bus speed for PIO modes; override with
idebus=xx
AMD7441: IDE controller on PCI bus 00 dev 39
AMD7441: chipset revision 4
AMD7441: not 100% native mode: will probe irqs later
AMD7441: disabling single-word DMA support (revision < C4)
    ide0: BM-DMA at 0xd800-0xd807, BIOS settings: hda:DMA, hdb:DMA
    ide1: BM-DMA at 0xd808-0xd80f, BIOS settings: hdc:DMA, hdd:DMA
hda: WDC WD800JB-00CRA1, ATA DISK drive
hdb: WDC WD307AA-00BAA0, ATA DISK drive
hdc: LITEON DVD-ROM LTD163D, ATAPI CD/DVD-ROM drive
hdd: AOPEN CD-RW CRW3248 1.10 20020301, ATAPI CD/DVD-ROM drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
ide1 at 0x170-0x177,0x376 on irq 15
blk: queue c03b9124, I/O limit 4095Mb (mask 0xffffffff)
hda: 156301488 sectors (80026 MB) w/8192KiB Cache, CHS=9729/255/63,
UDMA(100)
blk: queue c03b9270, I/O limit 4095Mb (mask 0xffffffff)
hdb: 60074784 sectors (30758 MB) w/2048KiB Cache, CHS=3739/255/63,
UDMA(66)
hdc: ATAPI 48X DVD-ROM drive, 512kB Cache, UDMA(33)
Uniform CD-ROM driver Revision: 3.12
hdd: ATAPI 48X CD-ROM CD-R/RW drive, 8192kB Cache, UDMA(33)
Partition check:
 hda: hda1 hda2 < hda5 >
 hdb: hdb1
Floppy drive(s): fd0 is 1.44M
FDC 0 is a post-1991 82077
loop: loaded (max 8 devices)
3c59x: Donald Becker and others. www.scyld.com/network/vortex.html
02:05.0: 3Com PCI 3c982 Dual Port Server Cyclone at 0xc800. Vers
LK1.1.16
Linux agpgart interface v0.99 (c) Jeff Hartmann
agpgart: Maximum main memory to use for agp memory: 816M
agpgart: Detected AMD 760MP chipset
agpgart: AGP aperture is 32M @ 0xfc000000
SCSI subsystem driver Revision: 1.00
kmod: failed to exec /sbin/modprobe -s -k scsi_hostadapter, errno = 2
es1371: version v0.30 time 18:48:06 Jan 11 2003
usb.c: registered new driver usbdevfs
usb.c: registered new driver hub
PCI: Enabling device 02:08.2 (0014 -> 0016)
PCI: No IRQ known for interrupt pin C of device 02:08.2. Probably buggy
MP table.
hcd.c: Found HC with no IRQ.  Check BIOS/PCI 02:08.2 setup!
uhci.c: USB Universal Host Controller Interface driver v1.1
PCI: Enabling device 02:08.0 (0014 -> 0016)
PCI: No IRQ known for interrupt pin A of device 02:08.0. Probably buggy
MP table.
usb-ohci.c: found OHCI device with no IRQ assigned. check BIOS settings!
PCI: Enabling device 02:08.1 (0014 -> 0016)
PCI: No IRQ known for interrupt pin B of device 02:08.1. Probably buggy
MP table.
usb-ohci.c: found OHCI device with no IRQ assigned. check BIOS settings!
usb.c: registered new driver hiddev
usb.c: registered new driver hid
hid-core.c: v1.8.1 Andreas Gal, Vojtech Pavlik <vojtech@suse.cz>
hid-core.c: USB HID support drivers
usb.c: registered new driver usblp
printer.c: v0.11: USB Printer Device Class driver
Initializing USB Mass Storage driver...
usb.c: registered new driver usb-storage
USB Mass Storage support registered.
mice: PS/2 mouse device common for all mice
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP, IGMP
IP: routing cache hash table of 8192 buckets, 64Kbytes
TCP: Hash tables configured (established 262144 bind 65536)
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
VFS: Mounted root (ext2 filesystem) readonly.
Freeing unused kernel memory: 124k freed



^ permalink raw reply	[flat|nested] 414+ messages in thread
* (no subject)
@ 2002-10-17  7:41 Rusty Russell
  2002-10-17 14:49 ` Roman Zippel
  0 siblings, 1 reply; 414+ messages in thread
From: Rusty Russell @ 2002-10-17  7:41 UTC (permalink / raw)
  To: Daniel Phillips, S; +Cc: Roman Zippel, linux-kernel

In message <E181zuY-0004Fl-00@starship> you write:
> On Thursday 17 October 2002 00:48, Rusty Russell wrote:
> > > On Wednesday 16 October 2002 08:11, Rusty Russell wrote:
> > > > It needs to be turned off when dealing with any interface which might
> > > > be used by one of the hard modules.  Which is pretty bad.
> > > 
> > > As far as I can see, preemption only has to be disabled during the 
> > > synchronize_kernel phase of unloading that one module, and this requireme
nt 
> > > is inherited neither by dependant or depending modules.
> > 
> > No, someone could already have been preempted before you start
> > synchronize_kernel().
> 
> I don't get that.  The sequence is:
> 
>   - turn off preemption
>   - unhook call points
>   - synchronize_kernel
>   - ...
> 
> which doesn't leave any preemption hole that I can see, so I can't comment
> on a couple of the other points until you clear that one up.

You mean that "turn off preemption" also wakes up anyone currently
preempted?  Otherwise they're preempted just inside one of those call
points.

> > Still a race between the zero check and the can't-increment state
> > setting.
> 
> But that one is easy: the zero check just takes the same spinlock as 
> TRY_INC_MOD_COUNT, then sets can't-increment only in the case the count
> is zero, considerably simpler than:

The current spinlock is horrible.  You could use a brlock, of course,
but I didn't mainly because of code bloat and speed.  My current code
looks like:

static inline int try_module_get(struct module *module)
{
	int ret = 1;

	if (module) {
		unsigned int cpu = get_cpu();
		if (likely(module->ref[cpu].live))
			local_inc(&module->ref[cpu].counter);
		else
			ret = 0;
		put_cpu();
	}
	return ret;
}

Which is small enough to be inlined quite nicely, and very fast.
Adding br_read_lock_irqsave() starts to get big and slow (at that
point it's more likely we want to move the module case out of line).

> > This is what my current code does: rmmod itself checks (if
> > /proc/modules available), then the kernel sets the module to
> > can't-increment, then checks again.  If the non-blocking flag is set,
> > it then re-animates the module and fails, otherwise it waits.
> 
> and leaves no window for spurious failure.  The still-initializing case is
> also easy, e.g., a filesystem module simply doesn't call register_filesystem
> until it's completely ready to service calls, so nobody is able to do
> TRY_INC_MOD_COUNT.

Consider some code which needs to know when cpus go up and down, so
registers a notifier.  If the notifier fires before the init is
finished, the notifier code will fail to "try_inc_mod_count()" and
won't call it (it doesn't do try_inc_mod_count at the moment, but
that's a bug).

I don't know of any code which does this now, but it is at least a
theoretical problem.

> > BTW, current patchset (2.5.43):
> 
> Thanks, I'll read them all on the 21st ;-)  The other thing I need to read
> closely is Roman's strategy for changing the module format, and the weird
> linker connections.

Roman dislikes linking in the kernel.  So did I until I wrote it: it's
really trivial (esp. compared with the code to coordinate with the
userspace linker properly).  And it exists today.  The linking takes
around 200 lines.  But, let's say his solution is 500 lines shorter
than mine.

For those five hundred lines, the new parameter infrastructure and
module versioning changes can be done *without* requiring any changes
in modutils.  If you've been following the module changes closely in
the last couple of years, you'll realize what a pain it has been to
introduce changes like licensing, etc.  This frees up our hand.

IMHO, the benifits of having it in-kernel outweigh the slight extra
size.

> > ...The second is the "die-mother-fucker-die"
> > version, which taints the kernel and just removes the damn thing.  For
> > most people, this is better than a reboot, and will usually "work".
> 
> Is there a case where removing a module would actually help?  What is
> the user going to do next, try to reinsert the same module?

Insert a fixed one, hopefully 8).  I was thinking for kernel
developers, and general robustness (eg. an oops inside a module leaves
its refcount at 1).

> > http://www.kernel.org/pub/linux/kernel/people/rusty/patches/Module/force-un
load.patch.gz
> 
> ERROR 404: Not Found.

Damn my fingers.  Updated (now applies on top of the others) but I
haven't tested this version yet (that's what I'm doing now):

http://www.kernel.org/pub/linux/kernel/people/rusty/patches/Module/forceunload.patch.gz

Cheers!
Rusty.
--
  Anyone who quotes me in their sig is an idiot. -- Rusty Russell.

^ permalink raw reply	[flat|nested] 414+ messages in thread
* (no subject)
@ 2002-10-11  0:11 sridhar vaidyanathan
  2002-10-11  0:21 ` Steven Dake
  0 siblings, 1 reply; 414+ messages in thread
From: sridhar vaidyanathan @ 2002-10-11  0:11 UTC (permalink / raw)
  To: linux-kernel


I am trying to debug a kernel over a remote serial console. I get 
Ignoring packet error ..
kgdb page suggests that it might be due to the speed mismatch. i tried 
stty ispeed 9600 ospeed 9600 < /dev/ttyS0 
on the development machine and have passed serial=0,9600n8 option and 
gdbbaud=9600 via lilo to the debug kernel. 

when i run 
%stty speed 
on the development machine it still reports 38400.
so i changed the gdbbaud and serial= values to 38400 on the test machine. even 
this doesn't work.
any ideas?also on the development machine when i invoke 
%gdb bzImage 
gdb reports that bzImage is not an Executable file format and it is unable to 
recognize the format. what is the problem?
-sridhar
ps: i have tried redirecting the kernel messages( without patching it with 
kgdb) over the serial line and read it with minicom . that works fine.

please email as i am not subscribed.

^ permalink raw reply	[flat|nested] 414+ messages in thread
* (no subject)
@ 2002-09-29 10:11 Richard Cooper
  2002-09-29 17:49 ` David Lloyd
  0 siblings, 1 reply; 414+ messages in thread
From: Richard Cooper @ 2002-09-29 10:11 UTC (permalink / raw)
  To: linux-kernel

unsubscribe linux-kernel


^ permalink raw reply	[flat|nested] 414+ messages in thread
* (no subject)
@ 2002-06-08 21:35 tushar  korde
  2002-08-21 16:30 ` Daniel Phillips
  0 siblings, 1 reply; 414+ messages in thread
From: tushar  korde @ 2002-06-08 21:35 UTC (permalink / raw)
  To: linux-kernel

hi folks,
 	as kmalloc allocates memory in power of 2 ( starting from 32 )
instead of the size requested. there are following problems :

  1) we are allocating at least 32 bytes in all cases ( most of 
the times it is not
required ).

  2) if we allocate large memory, internal fregmentation also 
increases.

  3) allocating more memory then the request often leads to 
programming errors
esp. when we store some data and read it back or try to get size 
of data stored
  ( though it can be handled but we have to take special care of 
it at every point ).

the solution to above problems may be that we dont allocate 
objects from the 13
general purpose caches, instead we make a new cache keep its 
address either in
cache_sizes or declare it global. now as the kmalloc is invoked 
check the memory size
requested if predefined sizes are not suitable then make a new 
object of the size
requested ( now here the definition of c_offset flag of cache 
descriptor may be
violated ) and allot it to our new cache and return it .

 	i know that there may be subtle problems in it's 
implementation.
i need your suggestions. is it worth to make efforts in this 
field.

keenly waitinf for ur reply
tushar korde
_________________________________________________________
Click below to visit monsterindia.com and review jobs in India or 
Abroad
http://monsterindia.rediff.com/jobs


^ permalink raw reply	[flat|nested] 414+ messages in thread
* (no subject)
@ 2002-05-31  8:04 Oliver Pitzeier
  2002-05-31 14:37 ` Alan Cox
  0 siblings, 1 reply; 414+ messages in thread
From: Oliver Pitzeier @ 2002-05-31  8:04 UTC (permalink / raw)
  To: 'linux-kernel'
  Cc: axp-kernel-list, alan, torvalds, 'Ivan Kokshaysky'

Hi volks/Linus/Alan/Ivan! :o)

I tried to compile kernel 2.5.19 on an alpha.

Can someone help me? I had the same problem already with kernel 2.5.18.
Kernel 2.5.15 works well. Everything above _not_.

Please help!!! Thanks!

While trying to compile 2.5.19, this happens:
<snip>
make[2]: Entering directory `/root/linux-2.5.19/drivers/base'
gcc -D__KERNEL__ -I/root/linux-2.5.19/include -Wall -Wstrict-prototypes
-Wno-trigraphs -O2 -fomit-frame-pointer -fno-strict-aliasing -fno-common
-pipe -mno-fp-regs -ffixed-8 -mcpu=ev5 -Wa,-mev6
-DKBUILD_BASENAME=bus -DEXPORT_SYMTAB -c -o bus.o bus.c
In file included from /root/linux-2.5.19/include/linux/thread_info.h:10,
                 from /root/linux-2.5.19/include/linux/spinlock.h:7,
                 from /root/linux-2.5.19/include/linux/tqueue.h:16,
                 from /root/linux-2.5.19/include/linux/sched.h:10,
                 from /root/linux-2.5.19/include/linux/device.h:30,
                 from bus.c:12:
/root/linux-2.5.19/include/linux/bitops.h: In function
`get_bitmask_order':
/root/linux-2.5.19/include/linux/bitops.h:77: warning: implicit
declaration of function `fls'
bus.c: At top level:
bus.c:114: parse error before `bus_init'
bus.c:115: warning: return type defaults to `int'
bus.c:120: warning: type defaults to `int' in declaration of
`core_initcall'
bus.c:120: warning: parameter names (without types) in function
declaration
bus.c:120: warning: data definition has no type or storage class
make[2]: *** [bus.o] Error 1
make[2]: Leaving directory `/root/linux-2.5.19/drivers/base'
make[1]: *** [_subdir_base] Error 2
make[1]: Leaving directory `/root/linux-2.5.19/drivers'
make: *** [drivers] Error 2
<snip>

Best regards,
  Greetz to the community,
    Oliver



^ permalink raw reply	[flat|nested] 414+ messages in thread
* (no subject)
@ 2002-04-18 11:23 Satish Mohan
  2002-04-18 11:35 ` François Cami
  0 siblings, 1 reply; 414+ messages in thread
From: Satish Mohan @ 2002-04-18 11:23 UTC (permalink / raw)
  To: linux-kernel

subscribe linux-kernel

^ permalink raw reply	[flat|nested] 414+ messages in thread
* RE:
@ 2002-04-09 13:25 Kuppuswamy, Priyadarshini
  0 siblings, 0 replies; 414+ messages in thread
From: Kuppuswamy, Priyadarshini @ 2002-04-09 13:25 UTC (permalink / raw)
  To: linux-kernel

Please ignore my earlier email. I didn't intend to send it to the list.

> -----Original Message-----
> From:	Kuppuswamy, Priyadarshini 
> Sent:	Tuesday, April 09, 2002 9:21 AM
> To:	linux-kernel@vger.kernel.org
> Subject:	
> 
> unsubscribe linux-kernel

^ permalink raw reply	[flat|nested] 414+ messages in thread
* (no subject)
@ 2002-03-31 19:17 mpaa3d
  2002-04-01  9:43 ` Vance Lankhaar
  0 siblings, 1 reply; 414+ messages in thread
From: mpaa3d @ 2002-03-31 19:17 UTC (permalink / raw)
  To: linux-kernel

Subject: Unauthorized Circumvention Device

MOTION PICTURE ASSOCIATION OF AMERICA, INC.
15503 VENTURA BOULEVARD
ENCINO, CALIFORNIA 91436

UNITED STATES
Anti-Piracy Operations
PHONE: (818) 728 - 8127
Email: MPAA3d@pacbell.net

April 1, 2003

Via Fax/Email

RE:         Illegal Provision of Circumvention Device
Site/URL:   http://www.kernel.org [and mirrors, with unknown IP addresses]
Reference#: 343313

Dear linux-kernel@vger.rutrgers.edu:

The Motion Picture Association (MPA) represents the following motion picture
production and distribution companies:

Columbia Pictures Industries, Inc.
Disney Enterprises, Inc.
Metro-Goldwyn-Mayer Studios Inc.
tro-Goldwyn-Mayer Studios Inc.
Paramount Pictures Corporation
TriStar Pictures, Inc.
Twentieth Century Fox Film Corporation
United Artists Pictures, Inc.
United Artists Corporation
Universal City Studios, Inc.
Warner Bros., a Division of Time Warner Entertainment Company, L.P.

We have received information that the above referenced Internet site is
providing a circumvention device commonly known as Linux.  Linux is a
software utility that circumvents the protection afforded by the Microsoft
Windows Operating Systems DRM implementation, therefore circumventing the
schemes designed for consumer content protection and permitting the copy of
protected contents in whole or partially.  As such, Linux is an unlawful
circumvention device within the meaning of the Digital Millennium Copyright
Act, Title 17 United States Code Section 1201(a)(2)(3).  Providing or
offering Linux to the public on your system or  network violates the
provisions of Section 1201(a)(2) which prohibit the manufacturing, importing
or offering to the public, providing, or otherwise trafficking in an
unlawful circumvention device.   (Title 17 United States Code 
Section 1201 et seq. hereafter is referred to as the DMCA).

We therefore demand that you take appropriate steps to cause the immediate
removal of Linux from the above identified Internet site, along with such
other actions as may be necessary or appropriate to suspend this illegal
activity. Failure to comply with this measure will subject you to liability
as described above.
We also request that you:

1. maintain and take whatever steps are necessary to prevent the destruction
of all records, including electronic records, in your possession or control
related to this Internet site, account holder or subscriber, and 

2. provide appropriate notice to the subscriber or account holder
responsible for the presence of Linux on your system or network, advising
him/her of the contents of this notice and directing that person to contact
the undersigned immediately at the email address provided above.

By copy of this letter, the owner of the above referenced Internet site
and/or email account is hereby directed to cease and desist from the conduct
complained of herein.

On behalf of the respective owners of the exclusive rights to the copyrighted
material at issue in this notice, we hereby state, pursuant to the DMCA that we
have a good faith belief that the acts complained of are not authorized by the
copyright owners, their respective agents, or the law.

Also pursuant to DMCA, we hereby state, under penalty of perjury under the
law of California and under the laws of the United States, that the
information in this notification is accurate and that we are authorized to
act on behalf of the owners of the exclusive rights being infringed as set
forth in this notification. 

Please contact us at the above listed address or by replying to this email
if you should have any questions.

Thank you for your cooperation in this matter.  Your prompt response is
requested.

Respectfully,

Haminshu Nigam
Director
Worldwide Internet Enforcement

^ permalink raw reply	[flat|nested] 414+ messages in thread
* RE:
@ 2002-02-20 17:55 Torrey Hoffman
  0 siblings, 0 replies; 414+ messages in thread
From: Torrey Hoffman @ 2002-02-20 17:55 UTC (permalink / raw)
  To: nimeesh, linux-kernel

nimeesh wrote:
 
> I'm new to linux.I'm trying network booting of linux
> system.System Conf.(intel 815 chipset ,PXE
> bios,3com905c-ethernet card)
> 
> In that i'm facing problem with kernel image and it's
> file system.
> 
> In that when i get the kernel image and filesystem.
> It gives me error as
> kernel panic : unable to mount root fs on 01:00
> 
> Is it necessary to use NFS or is it possible without
> that? Any special specification while creating kernel
> image and filesystem?

It sounds like you have PXE working well enough to have the 
BIOS download a PXE bootloader from a TFTP server, which 
then downloads a kernel image.  I assume you are using Peter 
Anvin's "pxelinux" boot loader?  
It is part of the "syslinux" package.

Anyway, you have at least two options for the root
file system.  You can use an NFS root, or you can use
an initial ramdisk.    I use an initial ramdisk.  My server 
has the standard ISC DHCP server, and Peter Anvin's TFTP server.

The DHCP server is configured in /etc/dhcpd.conf and
includes:

subnet 10.134.0.0 netmask 255.255.254.0
{
	# Not shown: options for DNS, router, domain name, 
	# default lease time, range, etc.

	# this is the important bit for PXE:
	filename "pxelinux.0"
}

The TFTP server contains the files:

pxelinux.0        (the pxelinux boot loader)
bzImage		(the kernel)
initrd.gz		(the initial ramdisk)
pxelinux.cfg/0A86 (the pxelinux config directory and file)

The Pxelinux.cfg configuration file I use is named "0A86" 
because the DHCP server assigns addresses "10.134.xxx.yyy", 
(10=0x0A, 134=0x86) and looks something like this:

DEFAULT MYNETBOOT
TIMEOUT 0
LABEL MYNETBOOT
  KERNEL bzImage
  APPEND initrd=initrd.gz root=/dev/ram

There is quite a bit of information on the network about how 
to create an initrd image.  Check the "HOWTO" documentation 
files that may have come with your Linux distribution.  
Also try "man initrd".

So here's how the pxe boot works from start to finish:

1. Client boots and enters PXE BIOS.
2. PXE BIOS does DHCP, gets IP address and filename option
3. PXE BIOS uses TFTP to download pxelinux.0 and boot from it
4. pxelinux.0 bootloader determines IP address, asks TFTP
   server for config file, finds "0A86" file and downloads it
5. pxelinux.0 reads config file, uses TFTP to download
   bzImage and initrd.gz
6. pxelinux boots bzImage kernel together with initrd.gz 
   ramdisk, kernel command line "root=/dev/ram" tells 
   kernel to use ramdisk as root filesystem
7. Kernel boots, mounts ramdisk, and then runs /linuxrc if it
   exists, otherwise runs /sbin/init just like booting from
   any other device.
8. linuxrc or init starts up the system or does whatever you
   want them to do.  Read the initrd man page for details.

Best wishes,

Torrey Hoffman

^ permalink raw reply	[flat|nested] 414+ messages in thread
* Re:
@ 2001-12-25 16:17 Manfred Spraul
  2001-12-25 19:14 ` Re: Legacy Fishtank
  0 siblings, 1 reply; 414+ messages in thread
From: Manfred Spraul @ 2001-12-25 16:17 UTC (permalink / raw)
  To: Colonel; +Cc: linux-kernel

> When I went to build 2.4.17 on a dinky box (486, 16M RAM), the
> config option was missing.  The box is a wall mount and is not very
> capable of multiple kernel experimentation alas.  Can someone
> supply some background as to what has happened?

It seems that RTNETLINK is now unconditionally enabled, I don't know
why.

--
    Manfred




^ permalink raw reply	[flat|nested] 414+ messages in thread
* (no subject)
@ 2001-12-05 16:05 Romain Giry
  2001-12-05 21:25 ` Dipak
  2001-12-06 10:43 ` Re: Romain Giry
  0 siblings, 2 replies; 414+ messages in thread
From: Romain Giry @ 2001-12-05 16:05 UTC (permalink / raw)
  To: mlist-linux-kernel

Hi

i would like to know how the network layer does to know what is the upper 
layer protocol in order to fill in correctly the protocol field in the 
header it adds to the packet before sending it. I'm doing a ethernet device 
that doesn't add any header to the packet but change the output device, 
then i should say the network device that the packet is like if it has been 
sent by the ip protocol.

Thanks,

Romain Giry


_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com


^ permalink raw reply	[flat|nested] 414+ messages in thread
* (no subject)
@ 2001-10-15  6:25 Dinesh  Gandhewar
  2001-10-15  6:56 ` David Ford
  0 siblings, 1 reply; 414+ messages in thread
From: Dinesh  Gandhewar @ 2001-10-15  6:25 UTC (permalink / raw)
  To: mlist-linux-kernel


Hello,
What is the effect of following statement at the end of function definition?
*(int *)0 = 0;	
Thanking you,
Dinesh 


^ permalink raw reply	[flat|nested] 414+ messages in thread
* (no subject)
@ 2001-10-02 15:30 Dinesh  Gandhewar
  2001-10-09 10:25 ` VDA
  0 siblings, 1 reply; 414+ messages in thread
From: Dinesh  Gandhewar @ 2001-10-02 15:30 UTC (permalink / raw)
  To: mlist-linux-kernel


Hello,
I have written a linux kernel module. The linux version is 2.2.14. 
In this module I have declared an array of size 2048. If I use this array, the execution of this module function causes kernel to reboot. If I kmalloc() this array then execution of this module function doesnot cause any problem.
Can you explain this behaviour?
Thnaks,
Dinesh 
 


^ permalink raw reply	[flat|nested] 414+ messages in thread
* (no subject)
@ 2001-10-02 15:29 Dinesh  Gandhewar
  2001-10-02 15:23 ` Tommy Reynolds
  2001-10-02 15:32 ` Re: Alex Bligh - linux-kernel
  0 siblings, 2 replies; 414+ messages in thread
From: Dinesh  Gandhewar @ 2001-10-02 15:29 UTC (permalink / raw)
  To: mlist-linux-kernel


Hello,
I have written a linux kernel module. The linux version is 2.2.14. 
In this module I have declared an array of size 2048. If I use this array, the execution of this module function causes kernel to reboot. If I kmalloc() this array then execution of this module function doesnot cause any problem.
Can you explain this behaviour?
Thnaks,
Dinesh 
 


^ permalink raw reply	[flat|nested] 414+ messages in thread
* Re:
@ 2001-08-16 12:18 Saravana
  0 siblings, 0 replies; 414+ messages in thread
From: Saravana @ 2001-08-16 12:18 UTC (permalink / raw)
  To: linux-kernel

> hi!
>    I am beginning learn to write a driver follow the
> Book "Beginnng Linux programming(Second
> Edition)".There is a example about char driver,I write
> as that,but I can open device,but can't read from it.I
> just copy some static data to user buffer as follow:
>    copy_to_user(buf, schar_buffer, count)

just check out if u got any perms(rw) on the device.. ?
sarvana

^ permalink raw reply	[flat|nested] 414+ messages in thread
* Re:
@ 2001-08-14  3:08 Parag Warudkar
  2001-08-14  3:17 ` Re: Keith Owens
  0 siblings, 1 reply; 414+ messages in thread
From: Parag Warudkar @ 2001-08-14  3:08 UTC (permalink / raw)
  To: Colonel; +Cc: linux-kernel

Additionally include/linux/modules/ksyms.ver 
requires following  two lines to be added for modules to work

#define __ver_no_llseek 8d4d42a6 
#define no_llseek       _set_ver(no_llseek)

Parag

On Mon, 13 Aug 2001 08:51:03 -0700 (PDT), Colonel wrote:

>  From: Colonel <klink@clouddancer.com>
>  To: paragw@excite.com
>  In-reply-to: <6558420.997690787827.JavaMail.imail@mayall.excite.com>
(message
>  	from Parag Warudkar on Mon, 13 Aug 2001 01:19:46 -0700 (PDT))
>  Subject: Re: Unresolved symbol: no_llseek
>  Reply-to: klink@clouddancer.com
>  References:  <6558420.997690787827.JavaMail.imail@mayall.excite.com>
>  
>     Date: Mon, 13 Aug 2001 01:19:46 -0700 (PDT)
>     From: Parag Warudkar <paragw@excite.com>
>     Reply-To: paragw@excite.com
>     Content-Type: text/plain; charset=us-ascii
>     X-Sender-Ip: 164.164.130.13
>  
>     Hi,
>  	 May be now you can answer my query :)?
>  
>     TIA,
>  
>     Parag
>  
>  
>  There was a msg posted from me replying to Linus about 15 minutes
>  prior to your query.  There are two missing symbols in kernel/ksyms
>  that need exporting.
>  
>  diff ksyms.c ksyms.c.~1~ 
>  245,246d244
>  < EXPORT_SYMBOL(generic_file_llseek);
>  < EXPORT_SYMBOL(no_llseek);
>  
>  
>  
>  
>  
>     In clouddancer.list.kernel, you wrote:
>  
>     >
>     >
>     >This is a multi-part message in MIME format.
>     >
>     >--------------InterScan_NT_MIME_Boundary
>     >Content-Type: text/plain; charset=us-ascii; format=flowed
>     >Content-Transfer-Encoding: 7bit
>     >
>     >
>     >In i810_audio: Unresolved symbol: no_llseek
>     >
>     >In agpgart : Unresolved symbol: no_llseek
>     >
>     >
>  
>  
>     I think I could tell you the answer, but it might violation this
disclaimer.
>  
>  
>  
>  
>     Parag Warudkar
>     Senior Systems Engineer
>     Wipro Technologies,
>     E-Commerce Division,
>     Lavelle Road,
>     Bangalore - 560001.
>     Ph: 2215010 Ext: 124.
>  
>  
>  
>  
>  
>     _______________________________________________________
>     http://inbox.excite.com
>  
>  


Parag Warudkar
Senior Systems Engineer
Wipro Technologies,
E-Commerce Division,
Lavelle Road,
Bangalore - 560001.
Ph: 2215010 Ext: 124.





_______________________________________________________
Send a cool gift with your E-Card
http://www.bluemountain.com/giftcenter/



^ permalink raw reply	[flat|nested] 414+ messages in thread
* (no subject)
@ 2001-07-25 18:44 Sumit Bhardwaj
  2001-07-25 19:18 ` Matthew M
  0 siblings, 1 reply; 414+ messages in thread
From: Sumit Bhardwaj @ 2001-07-25 18:44 UTC (permalink / raw)
  To: linux-kernel

I tried to compile linux 2.4.5 with gcc-3.0. It gave
the following error

kernel/sched.c : 'xtime' definition clash
In file include/linux/timer.h: line no. 540

after making the declaration

extern volatile struct xtime;

things worked fine.


__________________________________________________
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/

^ permalink raw reply	[flat|nested] 414+ messages in thread
* (no subject)
@ 2001-06-11  4:58 kiran.thirumalai
  2001-06-11  6:54 ` Anil Kumar
  0 siblings, 1 reply; 414+ messages in thread
From: kiran.thirumalai @ 2001-06-11  4:58 UTC (permalink / raw)
  To: linux-kernel

Hi,
Is there some kernel api to validate memory allocated using kmalloc.
Suppose, I allocate some memory using kmalloc and at a later point of
execution
I would like to validate if the memory allocated is not possibly freed by
some other thread.

Pls suggest a patch/pointers if any.
I also noticed a commented 'CONFIG_DEBUG_MALLOC' config option  (2.4.3
source),
It doesn't seem to be functional.  Any pointers towards the history behind
it would also be helpful.

Thanks in advance,
Kiran





^ permalink raw reply	[flat|nested] 414+ messages in thread
* Re:
@ 2001-05-22  4:25 Rajiv Majumdar
  0 siblings, 0 replies; 414+ messages in thread
From: Rajiv Majumdar @ 2001-05-22  4:25 UTC (permalink / raw)
  To: Anita Sinha; +Cc: linux-kernel, linux-kernel-owner


send a mail to majordomo@vger.kernel.org with 'help' in the body of the
mail

cheers
rajiv


^ permalink raw reply	[flat|nested] 414+ messages in thread
* (no subject)
@ 2001-05-08 19:48 Richard B. Johnson
  2001-05-08 21:33 ` george anzinger
  2001-05-09  0:36 ` Re: Andrew Morton
  0 siblings, 2 replies; 414+ messages in thread
From: Richard B. Johnson @ 2001-05-08 19:48 UTC (permalink / raw)
  To: Linux kernel


To driver wizards:

I have a driver which needs to wait for some hardware.
Basically, it needs to have some code added to the run-queue
so it can get some CPU time even though it's not being called.

It needs to get some CPU time which can be "turned on" or
"turned off" as a result of an interrupt or some external
input from  an ioctl().

So I thought that the "tasklet" would be ideal. However, the
scheduler "thinks" that a tasklet is an interrupt, so any
attempt to sleep in the tasklet results in a kernel panic,
"ieee scheduling in an interrupt..., BUG sched.c line 688".

Next, I added code to try queue_task(). This has the same problem.

Basically the procedure needs to do:

procedure()
{
    if(some_event)
        schedule_timeout(n);               /* Needs to sleep */
    else if(something_else)
        do_something();
   queue_task(procedure, &tq_immediate);   /* Needs to queue itself again */
}

Since I'm running against a time-line, I temporarily  gave the module
some CPU time through an ioctl(), i.e., a separate task that does nothing
except repeatably execute ioctl(GIVE_CPU, NULL); This shows that the
driver actually works. It's a GPIB driver so it needs to get the
CPU to find out if it's addressed to listen, etc. These events don't
produce interrupts.

So, what am I supposed to do to add a piece of driver code to the
run queue so it gets scheduled occasionally?

Cheers,
Dick Johnson

Penguin : Linux version 2.4.1 on an i686 machine (799.53 BogoMips).

"Memory is like gasoline. You use it up when you are running. Of
course you get it all back when you reboot..."; Actual explanation
obtained from the Micro$oft help desk.



^ permalink raw reply	[flat|nested] 414+ messages in thread
* (no subject)
@ 2001-04-18  0:15 Vibol Hou
  2001-04-18  0:26 ` Jaquemet Loic
  2001-04-20  2:47 ` Re: Francois Cami
  0 siblings, 2 replies; 414+ messages in thread
From: Vibol Hou @ 2001-04-18  0:15 UTC (permalink / raw)
  To: Linux-Kernel

Hi,

I'm using 2.4.4-pre3 and get this message occasionally when the system is
loaded:

Apr 17 16:10:12 omega kernel: eth0: Too much work in interrupt, status e401.
Apr 17 16:10:12 omega kernel: eth0: Too much work in interrupt, status e401.

The nic is a 3Com 3c905B. Is this a bad thing?

/proc/interrupts:
           CPU0       CPU1
  0:   13167527   12036422    IO-APIC-edge  timer
  1:          0          2    IO-APIC-edge  keyboard
  2:          0          0          XT-PIC  cascade
  4:      22773      19820    IO-APIC-edge
  8:          1          0    IO-APIC-edge  rtc
 15:          1          4    IO-APIC-edge  ide1
 17:   50001929   49606064   IO-APIC-level  eth0
 18:    2459038    2364252   IO-APIC-level  aic7xxx
NMI:          0          0
LOC:   25202946   25202942
ERR:          0

--
Vibol Hou
KhmerConnection
http://khmer.cc


^ permalink raw reply	[flat|nested] 414+ messages in thread
* Re:
@ 2001-03-22 18:02 Gunnar Ahlberg
  0 siblings, 0 replies; 414+ messages in thread
From: Gunnar Ahlberg @ 2001-03-22 18:02 UTC (permalink / raw)
  To: linux-kernel


I'm sorry for the empty message. As you can see it was 
delivered to the wrong address. 
Please disregard this posting.
Again, my apologies.

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



^ permalink raw reply	[flat|nested] 414+ messages in thread
* (no subject)
@ 2001-01-19 13:37 Robert Kaiser
  2001-01-19 14:33 ` Michael Rothwell
  0 siblings, 1 reply; 414+ messages in thread
From: Robert Kaiser @ 2001-01-19 13:37 UTC (permalink / raw)
  To: Steve Hill; +Cc: linux-kernel


On Thu Jan 18 16:30:30 2001 steve@navaho.co.uk wrote
> Has anyone had any luck getting a 2.4 kernel to run on Cobalt x86
> hardware?  It doesn't even seem to start (I get nothing on the screen from
>t he kernel, it just sits there and does nothing). :(

What processor does it use ? (386 or 486 perchance?)



----------------------------------------------------------------
Robert Kaiser                         email: rkaiser@sysgo.de
SYSGO RTS GmbH
Am Pfaffenstein 14                    phone: (49) 6136 9948-762
D-55270 Klein-Winternheim / Germany   fax:   (49) 6136 9948-10
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

^ permalink raw reply	[flat|nested] 414+ messages in thread

end of thread, other threads:[~2024-03-29  4:41 UTC | newest]

Thread overview: 414+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-07-31 23:46 TD CREDIT
  -- strict thread matches above, loose matches on Subject: below --
2024-03-07  6:07 KR Kim
2024-03-07  8:01 ` Miquel Raynal
2024-03-08  1:27   ` Re: Kyeongrho.Kim
     [not found]   ` <SE2P216MB210205B301549661575720CC833A2@SE2P216MB2102.KORP216.PROD.OUTLOOK.COM>
2024-03-29  4:41     ` Re: Kyeongrho.Kim
2023-11-27 13:37 [PATCH 2/3] net: microchip_t1s: add support for LAN867x Rev.C1 Andrew Lunn
2023-12-05 10:20 ` Félix Piédallu
2023-12-06 20:58   ` Ramón Nordin Rodriguez
2023-11-11  4:21 Andrew Worsley
2023-11-11  8:22 ` Javier Martinez Canillas
     [not found] <DB3PR10MB6835AF75D60D9A96465F35C2E8AAA@DB3PR10MB6835.EURPRD10.PROD.OUTLOOK.COM>
2023-11-06 12:55 ` Re: syzbot
2023-10-18 18:50 PIC probing code from e179f6914152 failing Mario Limonciello
2023-10-18 22:50 ` Thomas Gleixner
2023-10-19 21:20   ` Mario Limonciello
2023-10-23 15:59     ` Thomas Gleixner
2023-10-25  9:23       ` Thomas Gleixner
2023-10-25 14:41         ` Mario Limonciello
2023-10-25 15:25           ` David Lazar
2023-10-25 17:31             ` Thomas Gleixner
2023-10-25 21:04               ` [PATCH] x86/i8259: Skip probing when ACPI/MADT advertises PCAT compatibility, Thomas Gleixner
2023-10-25 22:11                 ` Mario Limonciello
2023-10-26  9:27                   ` Re: Thomas Gleixner
     [not found] <64b09dbb.630a0220.e80b9.e2ed@mx.google.com>
2023-07-14  8:05 ` Re: Andy Shevchenko
2023-05-11 12:58 Ryan Roberts
2023-05-11 13:13 ` Ryan Roberts
2023-03-12  6:52 [PATCH v2] uas: Add US_FL_NO_REPORT_OPCODES for JMicron JMS583Gen 2 Greg Kroah-Hartman
2023-03-27 13:54 ` Yaroslav Furman
2023-03-27 14:19   ` Greg Kroah-Hartman
2023-01-18 20:59 [PATCH v5 0/5] CXL Poison List Retrieval & Tracing alison.schofield
2023-01-27  1:59 ` Dan Williams
2023-01-27 16:10   ` Alison Schofield
2023-01-27 19:16     ` Re: Dan Williams
2023-01-27 21:36       ` Re: Alison Schofield
2023-01-27 22:04         ` Re: Dan Williams
2022-11-21 11:11 Denis Arefev
2022-11-21 14:28 ` Jason Yan
2022-09-14 13:12 Amjad Ouled-Ameur
2022-09-14 13:18 ` Amjad Ouled-Ameur
2022-05-15 20:36 [PATCH bpf-next 1/2] cpuidle/rcu: Making arch_cpu_idle and rcu_idle_exit noinstr Jiri Olsa
2023-05-20  9:47 ` Ze Gao
2023-05-21  3:58   ` Yonghong Song
2023-05-21 15:10     ` Re: Ze Gao
2023-05-21 20:26       ` Re: Jiri Olsa
2023-05-22  1:36         ` Re: Masami Hiramatsu
2023-05-22  2:07         ` Re: Ze Gao
2023-05-23  4:38           ` Re: Yonghong Song
2023-05-23  5:30           ` Re: Masami Hiramatsu
2023-05-23  6:59             ` Re: Paul E. McKenney
2023-05-25  0:13               ` Re: Masami Hiramatsu
2023-05-21  8:08   ` Re: Jiri Olsa
2023-05-21 10:09     ` Re: Masami Hiramatsu
2023-05-21 14:19       ` Re: Ze Gao
     [not found] <CANiq72k+5Rdj7i3Df2dcE6_OPYPXK3z5EWLKnY56sSMz4G3OvA@mail.gmail.com>
     [not found] ` <CAABZP2z64aYWfVSdXHaQopWc+BAbJJUGqtrju2iWER3DDTDFWg@mail.gmail.com>
     [not found]   ` <20220406170012.GO4285@paulmck-ThinkPad-P17-Gen-1>
     [not found]     ` <87pmls6nt7.fsf@mpe.ellerman.id.au>
     [not found]       ` <87k0bz7i1s.fsf@mpe.ellerman.id.au>
2022-04-13  5:11         ` Nicholas Piggin
2022-04-22 15:53           ` Thomas Gleixner
2022-04-23  2:29             ` Re: Nicholas Piggin
2022-04-21 16:41 Yury Norov
2022-04-21 23:04 ` John Hubbard
2022-04-21 23:09   ` Re: John Hubbard
2022-04-21 23:17   ` Re: Yury Norov
2022-04-21 23:21     ` Re: John Hubbard
2022-03-25  6:30 Michael S. Tsirkin
2022-03-25  7:52 ` Jason Wang
2022-03-25  9:10   ` Re: Michael S. Tsirkin
2022-03-25  9:20     ` Re: Jason Wang
2022-03-25 10:09       ` Re: Michael S. Tsirkin
2022-03-28  4:56         ` Re: Jason Wang
2022-03-28  5:59           ` Re: Michael S. Tsirkin
2022-03-28  6:18             ` Re: Jason Wang
2022-03-28 10:40               ` Re: Michael S. Tsirkin
2022-03-29  7:12                 ` Re: Jason Wang
2022-03-29 14:08                   ` Re: Michael S. Tsirkin
2022-03-30  2:40                     ` Re: Jason Wang
2022-03-30  5:14                       ` Re: Michael S. Tsirkin
2022-03-30  5:53                         ` Re: Jason Wang
2022-03-29  8:35                 ` Re: Thomas Gleixner
2022-03-29 14:37                   ` Re: Michael S. Tsirkin
2022-03-29 18:13                     ` Re: Thomas Gleixner
2022-03-29 22:04                       ` Re: Michael S. Tsirkin
2022-03-30  2:38                         ` Re: Jason Wang
2022-03-30  5:09                           ` Re: Michael S. Tsirkin
2022-03-30  5:53                             ` Re: Jason Wang
2022-04-12  6:55                   ` Re: Michael S. Tsirkin
2022-01-20 15:28 Myrtle Shah
2022-01-20 15:37 ` Vitaly Wool
2022-01-20 23:29   ` Re: Damien Le Moal
2022-02-04 21:45   ` Re: Palmer Dabbelt
     [not found] <20211126221034.21331-1-lukasz.bartosik@semihalf.com--annotate>
2021-11-29 21:59 ` Re: sean.wang
2021-11-02  9:48 [PATCH v5 00/11] Add support for X86/ACPI camera sensor/PMIC setup with clk and regulator platform data Hans de Goede
2021-11-02  9:49 ` [PATCH v5 05/11] clk: Introduce clk-tps68470 driver Hans de Goede
     [not found]   ` <163588780885.2993099.2088131017920983969@swboyd.mtv.corp.google.com>
2021-11-25 15:01     ` Hans de Goede
     [not found] <CAP7CzPcLhtXDyLudfmR2pWR5fzSQ_jhJSoRheH=cytoDnb_ujg@mail.gmail.com>
2021-09-14 15:37 ` Re: Nick Desaulniers
2021-08-12  9:21 Valdis Klētnieks
2021-08-12  9:42 ` SeongJae Park
2021-08-12 20:19   ` Re: Andrew Morton
2021-08-13  8:14     ` Re: SeongJae Park
2021-07-27  2:59 [PATCH v9] iomap: Support file tail packing Gao Xiang
2021-07-27 15:10 ` Darrick J. Wong
2021-07-27 15:23   ` Andreas Grünbacher
2021-07-27 15:30   ` Re: Gao Xiang
2021-06-06 19:19 Davidlohr Bueso
2021-06-07 16:02 ` André Almeida
2021-04-05  0:01 Mitali Borkar
2021-04-06  7:03 ` Arnd Bergmann
     [not found] <CAPncsNOFoUt7uEDEdihDTZY4pJsuPxt146W-L+Ju53SgZ6ezYw@mail.gmail.com>
     [not found] ` <CAPncsNMWCim1kozMyJaT7_suEnWyGadf1Kg1fzjyWfdGDVMZ3A@mail.gmail.com>
     [not found]   ` <CAPncsNOpMhn=N+9+uC8hx0shRE-5uhvHCmZKJ8X3=aAeja1sag@mail.gmail.com>
2021-03-18  6:51     ` Re: Jarvis Jiang
2021-01-19  0:10 David Howells
2021-01-20 14:46 ` Jarkko Sakkinen
     [not found] <CAGMNF6W8baS_zLYL8DwVsbfPWTP2ohzRB7xutW0X=MUzv93pbA@mail.gmail.com>
2020-12-02 17:09 ` Re: Kun Yi
2020-12-02  1:10 [PATCH] lib/find_bit: Add find_prev_*_bit functions Yun Levi
2020-12-02  9:47 ` Andy Shevchenko
2020-12-02 10:04   ` Rasmus Villemoes
2020-12-02 11:50     ` Yun Levi
     [not found]       ` <CAAH8bW-jUeFVU-0OrJzK-MuGgKJgZv38RZugEQzFRJHSXFRRDA@mail.gmail.com>
2020-12-02 18:22         ` Yun Levi
2020-12-02 21:26           ` Yury Norov
2020-12-02 22:51             ` Yun Levi
2020-12-03  1:23               ` Yun Levi
2020-12-03  8:33                 ` Rasmus Villemoes
2020-12-03  9:47                   ` Re: Yun Levi
2020-12-03 18:46                     ` Re: Yury Norov
2020-12-03 18:52                       ` Re: Willy Tarreau
2020-12-04  1:36                         ` Re: Yun Levi
2020-12-04 18:14                           ` Re: Yury Norov
2020-12-05  0:45                             ` Re: Yun Levi
2020-12-05 11:10                       ` Re: Rasmus Villemoes
2020-12-05 18:20                         ` Re: Yury Norov
2020-08-05 11:02 [PATCH v4] arm64: dts: qcom: Add support for Xiaomi Poco F1 (Beryllium) Amit Pundir
2020-08-06 22:31 ` Konrad Dybcio
2020-08-12 13:37   ` Amit Pundir
2020-06-30 17:56 Vasiliy Kupriakov
2020-07-10 20:36 ` Andy Shevchenko
2020-05-06  5:52 Jiaxun Yang
2020-05-06 17:17 ` Nick Desaulniers
     [not found] <5e7dc543.vYG3wru8B/me1sOV%chenanqing@oppo.com>
2020-03-27 15:53 ` Re: Lee Duncan
     [not found] <5e7dbb10.ulraq/ljeOm297+z%chenanqing@oppo.com>
2020-03-27  8:59 ` Re: Ilya Dryomov
2020-03-03 15:27 Gene Chen
2020-03-04 14:56 ` Matthias Brugger
2020-03-04 15:15   ` Re: Lee Jones
2020-03-04 18:00     ` Re: Matthias Brugger
2020-02-11 22:34 Rajat Jain
2020-02-12  9:30 ` Jarkko Nikula
2020-02-12 10:24   ` Re: Andy Shevchenko
     [not found] <f618ed4d-05ce-75cd-8cd9-24d8fe5a2551@samsung.com>
     [not found] ` <CGME20191105044921epcas1p2869157cceaf45351adf9dd2e59161db7@epcas1p2.samsung.com>
2019-11-05  4:54   ` Re: Chanwoo Choi
2019-10-27 21:36 Re: Margaret Kwan Wing Han
2019-09-24 19:49 Venkat Subbiah
     [not found] <CAK8P3a16=ktJm5B3c5-XS7SqVuHBY5+E2FwVUqbdOdWK-AUgSA@mail.gmail.com>
     [not found] ` <20190830202959.3539-1-msuchanek@suse.de>
2019-08-30 20:32   ` Arnd Bergmann
     [not found] <E1hUrZM-0007qA-Q8@sslproxy01.your-server.de>
2019-05-29 19:54 ` Re: Alex Williamson
2019-05-21  0:06 [PATCH v6 0/3] add new ima hook ima_kexec_cmdline to measure kexec boot cmdline args Prakhar Srivastava
2019-05-21  0:06 ` [PATCH v6 2/3] add a new ima template field buf Prakhar Srivastava
2019-05-24 15:12   ` Mimi Zohar
2019-05-24 15:42     ` Roberto Sassu
2019-05-24 15:47       ` Re: Roberto Sassu
2019-05-24 18:09         ` Re: Mimi Zohar
2019-05-24 19:00           ` Re: prakhar srivastava
2019-05-24 19:15             ` Re: Mimi Zohar
2019-04-12 23:06 RE, Sharifah Ahmad Mustahfa
     [not found] <20190319144116.400-1-mlevitsk@redhat.com>
2019-03-20 11:03 ` Felipe Franciosi
2019-03-20 19:08   ` Re: Maxim Levitsky
2019-03-21 16:12     ` Re: Stefan Hajnoczi
2019-03-21 16:21       ` Re: Keith Busch
2019-03-21 16:41         ` Re: Felipe Franciosi
2019-03-21 17:04           ` Re: Maxim Levitsky
2019-03-22  7:54             ` Re: Felipe Franciosi
2019-03-22 10:32               ` Re: Maxim Levitsky
2019-03-22 15:30               ` Re: Keith Busch
2019-03-25 15:44                 ` Re: Felipe Franciosi
2019-03-13 23:49 RE, LUIS EDUARDO CEPEDA CABRERA
2019-01-07 17:28 [PATCH] arch/arm/mm: Remove duplicate header Souptick Joarder
2019-01-17 11:23 ` Souptick Joarder
2019-01-17 11:28   ` Mike Rapoport
2019-01-31  5:54     ` Souptick Joarder
2019-01-31 12:58       ` Vladimir Murzin
2019-02-01 12:32         ` Re: Souptick Joarder
2019-02-01 12:36           ` Re: Vladimir Murzin
2019-02-01 12:41             ` Re: Souptick Joarder
2019-02-01 13:02               ` Re: Vladimir Murzin
2019-02-01 15:15               ` Re: Russell King - ARM Linux admin
2019-02-01 15:22                 ` Re: Russell King - ARM Linux admin
     [not found] <CAMkWEXP4Mm5x9rdrKn9xRNVm7vxqoL62ftxb+UcJFAiJ+U9X3A@mail.gmail.com>
2018-10-22  0:26 ` Re: Dave Airlie
2018-10-21 20:23   ` Re: Michael Tirado
2018-10-22  1:50     ` Re: Dave Airlie
2018-10-21 22:20       ` Re: Michael Tirado
2018-10-23  1:47       ` Re: Michael Tirado
2018-10-23  6:23         ` Re: Dave Airlie
     [not found] <1530911788-7033-1-git-send-email-santosh.shilimkar@oracle.com>
     [not found] ` <1530911788-7033-3-git-send-email-santosh.shilimkar@oracle.com>
2018-07-06 21:18   ` Re: Santosh Shilimkar
2018-01-11 17:16 Fabian Huegel
2018-01-11 17:25 ` Ben Evans
2017-11-13 14:55 Re: Amos Kalonzo
2017-09-07  8:50 Re: Quick Loan
2017-08-18 19:47 Re: Jessy
2017-07-15  3:29 Re: Saif Al-Islam
2017-07-07 17:04 Mrs Alice Walton
2017-05-28 13:39 RE: Lasek László
2017-05-03  6:23 H.A
2017-04-28  8:20 Anatolij Gustschin
2017-04-28  8:43 ` Linus Walleij
2017-04-28  9:26   ` Re: Anatolij Gustschin
2017-02-23 15:09 Qin's Yanjun
2017-01-07 14:47 Information
2016-11-15  4:40 Apply
2016-11-08 13:46 vaserman
2016-11-02  2:36 U
2016-07-21 21:50 Amit Jain
2016-07-04 15:47 Re: Mr. Bun Sam
2016-07-02 11:30 Re: Mr. Bun Sam
2016-06-27  8:24 Re: Fidelity Loans
2016-02-10 14:36 Petr Mladek
2016-02-10 14:44 ` Steven Rostedt
2016-02-08  3:11 Qatar Foundation
2016-01-26 20:52 Ms Nadia Mohammed
2016-01-15  2:39 Re: Trust Guarantee
2015-12-18 11:50 Re: 
2015-12-11  9:30 Re: Матвеева Руслана
     [not found] <D0613EBE33E8FD439137DAA95CCF59555B7A5A4D@MGCCCMAIL2010-5.mgccc.cc.ms.us>
2015-11-24 13:21 ` Amis, Ryann
     [not found] <CA+47Ykimr0d9cR35aWoCtm8JoXUYjKFXL0HJ-c=EE_suTAPR8w@mail.gmail.com>
2015-11-07 17:33 ` bbmbbm1
2015-11-07 16:48 Re: Mohammed
2015-10-29  2:40 
2015-10-23 14:46 RE: MajorAlan
2015-10-21  2:26 Mohammed
2015-10-08  8:30 Re BRGF
2015-09-01 16:06 Zariya
2015-09-01 14:14 Mika Penttilä
2015-09-01 15:22 ` Fabio Estevam
2015-09-01 12:01 Re: Zariya
2015-08-19 13:01 Re: christain147
2015-07-24 10:34 Re: Mrs Nadia  Mohammed 
     [not found] <CACy=+DtdZOUT4soNZ=zz+_qhCfM=C8Oa0D5gjRC7QM3nYi4oEw@mail.gmail.com>
2015-07-11 18:37 ` Re: Mustapha Abiola
     [not found] <CAHxZcryF7pNoENh8vpo-uvcEo5HYA5XgkZFWrLEHM5Hhf5ay+Q@mail.gmail.com>
2015-07-05 16:38 ` Re: t0021
     [not found] <E1Yz4NQ-0000Cw-B5@feisty.vs19.net>
2015-05-31 15:37 ` Re: Roman Volkov
2015-05-31 15:53   ` Re: Hans de Goede
2015-05-22  0:17 Re: kontakt
     [not found] <90BA5B564A2E4B4782C6F4398C32EE104E54369A@NHS-PCLI-MBC003.AD1.NHS.NET>
2015-05-21 10:49 ` Ratnakumar Sagana (KING'S COLLEGE HOSPITAL NHS FOUNDATION TRUST)
     [not found] <9E5F73AAFC185F49B0D37FE62E65D6C20724A9D8@XSERVER23A.campus.tue.nl>
2015-05-10 13:03 ` RE: Singer, W.P.
2015-04-21  7:43 Galaxy Darlehen Firma
     [not found] <CAONCqDfSP9DSWwPSDqz4NS6YHmzwMo=6VnRURRAJZLeGE_QKYA@mail.gmail.com>
2015-04-07 18:47 ` Re: Wilson Aggard
2015-04-01 21:56 Re: Globale Trust Company
2015-03-04 10:29 Quentin Lambert
2015-03-04 10:32 ` Quentin Lambert
2014-12-18 18:08 Re: Peter Page
2014-12-01 13:02 Re: Quan Han
2014-11-14 20:49 Re: salim
2014-11-14 18:56 milke
     [not found] <E1XgbTy-00072R-N3@feisty.vs19.net>
2014-10-21 15:48 ` Patrik Lundquist
     [not found] <E1Xf0HT-0005ZQ-OP@feisty.vs19.net>
2014-10-17  5:49 ` Re: Hillf Danton
2014-10-13  6:18 Re: geohughes
     [not found] <5633293EA8BBC640804038866F5D329F0B3A17@mail00.baptist.local>
2014-09-30 17:20 ` Sonya Wright
2014-09-20 19:45 Richard Wong
2014-09-16 14:54 Re: promocion_derechos.isna
     [not found] <AB37FB01B00BF44E85C75F6CFEC35E7D47324643@LPPTCPMXMBX01.LPCH.NET>
2014-09-15 23:42 ` Mandic, Andrew
2014-09-16  0:44 ` RE: Mandic, Andrew
     [not found] <6A286AB51AD8EC4180C4B2E9EF1D0A027AAD7EFF1E@exmb01.wrschool.net>
2014-09-08 16:58 ` RE: Deborah Mayher
2014-08-18 15:38 Mrs. Hajar Vaserman.
     [not found] <E1XFOD5-00007y-8L@feisty.vs19.net>
2014-08-07 14:23 ` Re: Pranith Kumar
2014-07-29  7:17 Re: eye2eye
     [not found] <blk-mq updates>
2014-04-14  8:30 ` Christoph Hellwig
2014-04-15 20:16   ` Jens Axboe
2014-03-10  3:04 Re: inforbonus
2014-03-10  3:01 Re: inforbonus
2014-01-11  2:11 Re: Mr. Jerry Natai
2013-12-30 10:43 st2
2013-12-30  9:06 RE: funds2
2013-12-20 11:49 RE: Unify Loan Company
2013-11-30  3:46 Bin Sumari
2013-11-07 12:09 Re: mypersonalmailbox1
2013-09-03 23:50 Matthew Garrett
2013-09-04 15:53 ` Kees Cook
2013-09-04 16:05   ` Re: Josh Boyer
2013-08-23 18:04 Andreas Werner
2013-08-23 21:10 ` Andy Lutomirski
     [not found] <B719EF0A9FB7A247B5147CD67A83E60E011FEB76D1@EXCH10-MB3.paterson.k12.nj.us>
2013-08-23 10:47 ` Ruiz, Irma
2013-08-07 20:43 Western Union
2013-07-08  4:52 Re: Wesstern Union money Transfer
2013-06-28 10:14 Re: emirates
2013-06-28 10:12 Re: emirates
2013-06-20 12:28 tingwei liu
2013-06-20 12:51 ` Jiri Slaby
2013-06-24  1:43   ` Re: tingwei liu
2013-06-24  8:24     ` Re: Jiri Slaby
     [not found] ` <CA+qZnSSPxO3h0v7An3R7e-HHs+bi4Ua-LE9coJtQL8CFWOHNBA@mail.gmail.com>
2013-06-27  5:12   ` Re: tingwei liu
2013-05-14 13:07 Re: info
2013-04-27 13:20 PRIVATE BUSINESS
2013-04-02 13:29 Mrs Akilah Saeedi
2013-03-26  2:26 Re: Mrs Akilah Saeedi
2013-02-04  0:47 Re: JUMBO PROMO
2013-01-27 21:59 Re: Congjun Yang
2013-01-13 19:58 Re: Michael A. Purwoadi
2012-11-21 14:04 roman
2012-11-21 14:50 ` Alan Cox
2012-10-30  9:19 Re: wumin_tsinghua
2012-10-06 23:15 David Howells
2012-10-07  6:36 ` Geert Uytterhoeven
2012-10-11  9:57   ` Re: Will Deacon
2012-09-04 14:40 [GIT PULL] sound fixes for 3.6-rc5 Takashi Iwai
2012-09-06  6:02 ` Markus Trippelsdorf
2012-09-06  6:33   ` Re: Daniel Mack
2012-09-06  6:45     ` Re: Markus Trippelsdorf
2012-09-06  6:48     ` Re: Takashi Iwai
2012-09-06  6:53       ` Re: Markus Trippelsdorf
2012-08-10  5:32 devendra.aaru
2012-08-10  8:45 ` Linus Walleij
2012-08-10 10:47 ` Re: Bernd Petrovitsch
2012-08-09 13:54 Fengguang Wu
2012-08-09 17:29 ` Mauro Carvalho Chehab
2012-08-06 16:59 anish kumar
2012-08-06 17:05 ` Maarten Lankhorst
2012-07-12 11:43 Re: macckone
2012-06-18  9:44 sakthiperumal karuthasamy
2012-06-18 11:52 `  
2012-05-20 22:20 Re: Mr. Peter Wong
2011-12-13  3:49 Re: Ryan Black
2011-11-22 12:06 Re: Balbir Singh
2011-11-09 11:58 Re: pradeep Annavarapu
2011-11-08  1:58 linux-next: manual merge of the bluetooth tree with Linus tree Stephen Rothwell
2011-11-08  2:26 ` Wu Fengguang
2011-11-08  4:40   ` Stephen Rothwell
2011-10-28 16:03 Re: Young Chang
2011-10-28 15:55 Re: Young Chang
2011-10-26 20:51 Re: bfeely
2011-08-21 19:22 Re: jeffrice
2011-08-18 22:07 San Mehat
2011-08-18 22:08 ` San Mehat
2011-08-13 10:59 Mr. Kenneth Williams
2011-08-06 13:23 RE: John Coker
2011-07-22  0:32 Jason Baron
2011-07-22  0:57 ` Paul Turner
2011-05-23  9:11 Re: Young Chang
2011-05-18 15:57 Re: alex zaim
2011-05-06 18:52 Nat Gurumoorthy
2011-05-06 19:13 ` Guenter Roeck
2011-05-06 20:00   ` Re: Natarajan Gurumoorthy
2011-05-01 13:35 Re: lotto
2011-04-10  1:20 Re: Young Chang
2011-04-07 21:00 Re: Tim Peters
2011-02-23  9:18 Irish Online News Center
2011-02-01 16:39 young chang
2010-12-04 21:06 FreeLotto Online Promo
     [not found] <3E0D78C2-CEAF-42C3-9840-20B01AA4EFC7@vsecurity.com>
2010-11-21 18:33 ` Dan J. Rosenberg
2010-11-22 17:02   ` Re: Vasiliy Kulikov
2010-10-14 11:47 Re : World Bank
2010-10-09 17:52 Mr.Young Chang
2010-07-20  0:22 Re: wins
2010-07-17  3:37 Re: SINOPEC OIL AND GAS COMPANY
2010-07-11 21:42 Western Union
2010-07-11 22:23 ` Noah McNallie
     [not found] <7a07eea248913e9f.4c3919f6@access.k12.wv.us>
2010-07-11  0:49 ` Re: tkprice
2010-07-02 20:13 Re: ($10,500,000.00) Donation for Charitable Goals
2010-07-02 19:29 Re: ($10,500,000.00) Donation for Charitable Goals
2010-07-01 16:09 Re ! BRITISH COLUMBIA
2010-07-01 10:49 FUJITA Tomonori
2010-07-01 12:29 ` Jens Axboe
2010-06-14 20:26 [PATCH 0/8] Fix gcc 4.6.0 set but not used warning messages Justin P. Mattock
2010-06-14 20:26 ` [PATCH 7/8]ieee1394/sdp2 Fix warning: variable 'unit_characteristics' set but not used Justin P. Mattock
2010-06-14 21:44   ` [PATCH] ieee1394: sbp2: remove unused code Stefan Richter
2010-06-14 22:35     ` Justin P. Mattock
2010-06-14 23:22       ` Stefan Richter
2010-06-14 23:58         ` Justin P. Mattock
2010-06-13  6:16 Mike Gilks
2010-06-13  8:58 ` Tejun Heo
2010-06-08  4:27 FRL
2010-06-08  4:05 RE: FRL
2010-05-11 22:28 RE: Euro-Millions
     [not found] <20100510223054.luv5qlqdlp28g08o@webmail.wcsd.k12.oh.us>
     [not found] ` <20100510223506.77ylw39bns84c80c@webmail.wcsd.k12.oh.us>
     [not found]   ` <20100510223656.m8nzy8mwqf44g8g8@webmail.wcsd.k12.oh.us>
2010-05-11  4:19     ` Mr. Vincent Hong
2010-05-08  2:56 Promo
2010-05-08  0:01 IRISH NEWS CENTRE
2010-05-07 11:39 Re: William Wilcox
2010-05-07 11:37 Re: William Wilcox
2010-04-14 12:54 Alan Cox
2010-04-14 13:35 ` Jean Delvare
2010-04-02 23:17 RE; Mrs Claire page
2010-03-23  7:50 RE, FROM CENTRAL BANK
2010-03-11 16:40 Monica D.
2010-02-25 13:39 Re; William Wilcox
2010-01-16  1:54 Capt Chris P. Mark
2010-01-13  0:48 Jeff Mahoney
2010-01-13  8:24 ` David Woodhouse
2010-01-09 17:03 Ustin Gavrie
2009-12-19 17:38 OFFICE OF THE SENATE
2009-12-12 16:04 T Dent
2009-12-13  5:55 ` andrew hendry
2009-12-08  6:23 Irish News Center
2009-11-26  1:03 [PATCH 1/2] hw_random: core updates to allow more efficient drivers Matt Mackall
2009-11-26 10:49 ` Ian Molton
2009-11-26 11:38   ` Matt Mackall
2009-11-26 11:48     ` Re: Ian Molton
2009-11-27 22:54       ` Re: Matt Mackall
2009-11-20 13:29 Jerome Glisse
2009-12-01 23:53 ` Dave Airlie
2009-12-02  7:17   ` Re: Thomas Hellstrom
     [not found] <cover.1257602781.git.andre.goddard@gmail.com>
     [not found] ` <7206ef594e67a240a842339f520284de6569b1fc.1257602781.git.andre.goddard@gmail.com>
     [not found]   ` <31525.1257770343@redhat.com>
2009-11-09 15:31     ` Re: André Goddard Rosa
2009-11-05  3:24 Re: Irish News Centre
2009-11-01 17:00 Re: Irish News Centre
2009-10-10 19:13 Irish News Center
2009-09-26 15:22 RE: Irish News Center
2009-09-25 23:13 RE: Irish News Center
2009-06-20 19:45 Kay Sievers
2009-06-21  9:04 ` Takashi Iwai
2009-06-22 12:56 ` Re: David Woodhouse
2009-01-11  3:41 Jose Luis Marchetti
2009-01-11  5:44 ` Cooper Yuan
2008-11-30 11:23 Re: Frank
2008-10-11  7:30 Yudha Harimantoro T
2008-10-11 15:12 ` Bill Davidsen
2008-10-13  6:18   ` Re: Yudha Harimantoro T
2008-10-13  8:29     ` Re: Yudha Harimantoro T
2008-10-13 12:03       ` Re: Alan Jenkins
     [not found] <0K6B0005EN54GNO0@l-daemon>
2008-08-29  0:14 ` Re: Robert Hancock
     [not found] <alpine.LFD.1.10.0807271037190.3486@nehalem.linux-foundation.org>
2008-07-27 22:37 ` Trond Myklebust
2008-07-09 15:47 Mathieu Desnoyers
2008-07-09 16:07 ` Eduard - Gabriel Munteanu
2008-07-09 16:35   ` Re: Mathieu Desnoyers
2008-05-20 12:34 Lukas Hejtmanek
2008-05-20 12:40 ` Oliver Neukum
2008-04-09  8:45 Andreas Grimm
2008-04-10  1:14 ` Lee Revell
2008-02-03 11:13 am kara
2008-02-03 18:23 ` Benny Halevy
2007-11-10  1:18 Luck, Tony
2007-11-10  1:42 ` Eric Dumazet
2007-11-11  5:18   ` Re: David Miller
2007-08-14 23:04 [PATCH 0/24] make atomic_read() behave consistently across all architectures Chris Snook
2007-08-15  6:49 ` Herbert Xu
2007-08-15  8:18   ` Heiko Carstens
2007-08-15 13:53     ` Stefan Richter
2007-08-15 14:35       ` Satyam Sharma
2007-08-15 14:52         ` Herbert Xu
2007-08-15 16:09           ` Stefan Richter
2007-08-15 16:27             ` Paul E. McKenney
2007-08-15 18:31               ` Segher Boessenkool
2007-08-15 18:57                 ` Paul E. McKenney
2007-08-15 19:54                   ` Satyam Sharma
2007-08-15 20:47                     ` Segher Boessenkool
2007-08-16  0:36                       ` Satyam Sharma
2007-08-16  1:38                         ` Segher Boessenkool
2007-08-07 16:34 Brian J. Murrell
2007-08-09 20:33 ` Mark Lord
2007-08-09 21:04   ` Re: Brian J. Murrell
     [not found] <FC1D1B23302A22499C60C967336B2AE00186B15C@pdsmsx411.ccr.corp.intel.com>
2007-07-24 13:40 ` Re: Shaohua Li
2007-02-09  6:29 Priyanka Sharma
2007-02-10  2:41 ` hackmiester (Hunter Fuller)
2006-08-16  9:30 Re: shane
2006-05-16 10:34 Chris Boot
2006-05-16 12:34 ` Arnaldo Carvalho de Melo
2006-03-11  1:00 Re: Alec
2006-03-03 14:54 Re: Kennedy
2006-02-23 12:16 Re: Norberto
2006-02-18 16:04 Re: Donne
2006-02-04 14:33 Re: Ira Jackson 
2006-01-27 10:05 sarat
2006-01-27 10:09 ` Arjan van de Ven
2005-12-31  0:27 system keeps freezing once every 24 hours / random apps crashing Alistair John Strachan
2005-12-31  0:42 ` Mark v Wolher
2005-12-31  0:51   ` Alistair John Strachan
2005-12-31  0:54     ` Mark v Wolher
2005-12-31 10:31       ` Mark v Wolher
2005-12-31 11:08         ` Jesper Juhl
2005-12-31 11:40           ` Mark v Wolher
2005-12-31 11:49             ` Jesper Juhl
2005-12-31 12:46               ` Mark v Wolher
2005-12-31 15:18                 ` Mark v Wolher
2005-12-31 16:34                   ` Sami Farin
2005-12-31 16:48                     ` Mark v Wolher
2006-01-01  2:26                       ` Mark v Wolher
2006-01-01 13:06                         ` Mark v Wolher
2006-01-01 14:47                           ` Mark v Wolher
2006-01-01 18:38                             ` Jiri Slaby
2006-01-01 18:49                               ` Mark v Wolher
2006-01-01 19:12                                 ` Jiri Slaby
2006-01-01 19:37                                   ` Mark v Wolher
2005-12-02 16:03 Yu, Luming
2005-12-02 16:46 ` Dmitry Torokhov
2005-12-02 20:11 ` Re: Miloslav Trmac
2005-11-09 16:13 Nestor Velazquez
2005-11-09 16:17 ` Alejandro Bonilla
2005-09-21 13:20 Robert.Boermans
2005-09-21 13:27 ` Denis Vlasenko
2005-06-28  9:18 d binderman
2005-06-28 11:03 ` Andrew Morton
2005-06-28  9:15 d binderman
2005-06-28 11:00 ` Andrew Morton
     [not found] <360D47F92A8ACCH7@vger.kernel.org>
2005-05-30  2:49 ` Re: radej
2005-05-06 20:23 Edison Giovanny Mendoza
2005-05-06 20:32 ` Alejandro Bonilla
2005-03-25  7:03 Søren Lott
2005-03-25  7:18 ` Jeff Garzik
2005-03-20  5:24 Re: info
2005-03-08 16:32 Peter W. Morreale
2005-03-08 19:32 ` Ross Biro
2005-03-05 10:11 Raffaele Ianniello
2005-03-05 18:14 ` Randy.Dunlap
2005-02-26 14:57 Yong Haynes
2005-02-17 17:14 Deepti Patel
2005-02-17 17:46 ` Matthias-Christian Ott
2005-01-19 14:25 Gmail
2005-01-19 15:22 ` Paolo Ornati
2004-11-08  7:39 Marcelo Tosatti
2004-11-08 11:08 ` Paolo Ciarrocchi
2004-11-08  8:34   ` Re: Marcelo Tosatti
2004-11-08 22:08     ` Re: Guennadi Liakhovetski
2004-09-19 12:29 plt
     [not found] ` <200409191508.33537.Norbert@edusupport.nl>
     [not found]   ` <1095607945.414da6891fc94@webmail.taylorassociate.com>
2004-09-19 16:31     ` Norbert van Nobelen
2004-06-27 14:18 Vinu Moses
2004-06-27 20:14 ` Vinu Moses
2004-03-17 22:03 Kendrick Logan
2004-03-07 20:08 Michael Frank
2004-03-07 20:26 ` John Bradford
2004-02-22 17:51 redzic fadil
2004-02-22 18:48 ` Larry Reaves
2004-02-14 23:17 Re: Alexandr Chernyy
     [not found] <7A25937D23A1E64C8E93CB4A50509C2A0310F099@stca204a.bus.sc.rolm.com>
2004-02-05 17:02 ` Re: Tommy Reynolds
2003-12-11 23:37 Hettinger Tamas
2003-12-12  1:29 ` Jonathan Corbet
2003-12-05 17:36 gmack
2003-12-05 23:16 ` Oliver Hunt
2003-12-03 15:08 Bloch, Jack
2003-12-04  4:56 ` Raj
2003-09-10  2:20 John Yau
2003-09-10  2:31 ` Nick Piggin
2003-08-25 13:53 Marcelo Tosatti
2003-08-25 14:12 ` Nick Piggin
2003-08-12 13:55 Catalin BOIE
2003-08-12 17:05 ` Ian Hastie
2003-07-16 18:36 Sir Ace
2003-07-16 23:10 ` jiho
2003-06-30  3:16 usenet
2003-06-30  8:09 ` Bruce Harada
2003-06-30  8:23   ` Re: Matti Aarnio
2003-06-03 23:51 Justin T. Gibbs
2003-06-03 23:58 ` Marc-Christian Petersen
2003-04-30 21:39 Mauricio Oliveira Carneiro
2003-05-01  0:03 ` Eyal Lebedinsky
     [not found] <001e01c2d9ef$01cdc970$0200a8c0@wsl3>
2003-02-21 21:34 ` Re: b_adlakha
2003-02-08 10:40 Re: Manfred Spraul
2003-01-12 13:28 Philip K.F. Hölzenspies
2003-01-12 17:57 ` Shawn Starr
2002-10-17  7:41 Rusty Russell
2002-10-17 14:49 ` Roman Zippel
2002-10-11  0:11 sridhar vaidyanathan
2002-10-11  0:21 ` Steven Dake
2002-09-29 10:11 Richard Cooper
2002-09-29 17:49 ` David Lloyd
2002-06-08 21:35 tushar  korde
2002-08-21 16:30 ` Daniel Phillips
2002-05-31  8:04 Oliver Pitzeier
2002-05-31 14:37 ` Alan Cox
2002-04-18 11:23 Satish Mohan
2002-04-18 11:35 ` François Cami
2002-04-09 13:25 Kuppuswamy, Priyadarshini
2002-03-31 19:17 mpaa3d
2002-04-01  9:43 ` Vance Lankhaar
2002-02-20 17:55 Torrey Hoffman
2001-12-25 16:17 Manfred Spraul
2001-12-25 19:14 ` Re: Legacy Fishtank
2001-12-25 21:23   ` Re: Kurt Roeckx
2001-12-25 22:03   ` Re: Alan Cox
2002-01-03  0:06   ` Re: David S. Miller
2002-01-03  0:23     ` Re: Alan Cox
2001-12-05 16:05 Romain Giry
2001-12-05 21:25 ` Dipak
2001-12-06 10:43 ` Re: Romain Giry
2001-12-06 11:28   ` Re: Alan Cox
2001-10-15  6:25 Dinesh  Gandhewar
2001-10-15  6:56 ` David Ford
2001-10-15 16:02   ` Re: Timur Tabi
2001-10-02 15:30 Dinesh  Gandhewar
2001-10-09 10:25 ` VDA
2001-10-02 15:29 Dinesh  Gandhewar
2001-10-02 15:23 ` Tommy Reynolds
2001-10-02 15:32 ` Re: Alex Bligh - linux-kernel
2001-08-16 12:18 Re: Saravana
2001-08-14  3:08 Re: Parag Warudkar
2001-08-14  3:17 ` Re: Keith Owens
2001-07-25 18:44 Sumit Bhardwaj
2001-07-25 19:18 ` Matthew M
2001-06-11  4:58 kiran.thirumalai
2001-06-11  6:54 ` Anil Kumar
2001-05-22  4:25 Rajiv Majumdar
2001-05-08 19:48 Richard B. Johnson
2001-05-08 21:33 ` george anzinger
2001-05-09 13:04   ` Re: Richard B. Johnson
2001-05-09 14:10     ` Re: Alan Cox
2001-05-09 16:59       ` Re: george anzinger
2001-05-09 17:15         ` Re: Alan Cox
2001-05-09  0:36 ` Re: Andrew Morton
2001-04-18  0:15 Vibol Hou
2001-04-18  0:26 ` Jaquemet Loic
2001-04-18  0:32   ` Re: Jeff Garzik
2001-04-20  2:47 ` Re: Francois Cami
2001-04-21  1:26   ` Re: Andrew Morton
2001-03-22 18:02 Re: Gunnar Ahlberg
2001-01-19 13:37 Robert Kaiser
2001-01-19 14:33 ` Michael Rothwell

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).