Pali Rohár | 27 Nov 21:01 2014
Picon

Missing MODALIAS in /sys/devices/system/cpu/uevent

Hello,

on 3.18-rc5 I have empty cpu uevent file, but modalias file is 
populated. See:

$ cat /sys/devices/system/cpu/uevent 
$ cat /sys/devices/system/cpu/modalias 
cpu:type:x86,ven0000fam0006mod003C:feature:,0000,0001,0002,0003,0004,0005,0006,0007,0008,0009,000B,000C,000D,000E,000F,0010,0011,0013,0015,0016,0017,0018,0019,001A,001B,001C,001D,001F,002B,0034,003A,003B,003D,0068,006B,006C,006D,006F,0070,0072,0074,0075,0076,0078,007C,007D,0080,0081,0082,0083,0084,0085,0086,0087,0088,0089,008B,008C,008D,008E,008F,0091,0093,0094,0095,0096,0097,0098,0099,009A,009B,009C,009D,009E,00C0,00C5,00E0,00E1,00E3,00E5,00E6,00E7,0100,0101,0102,0103,0104,0120,0121,0123,0124,0125,0127,0128,0129,012A,012B,012D,0140

For all other devices in /sys/devices/ which have modalias 
content there is also MODALIAS= line in uevent file.

Is cpu device special? Or why it is only one device which has 
modalias file but is missing MODALIAS= line in uevent file?

What userspace application should use for reading modalias 
string? File modalias or file uevent?

--

-- 
Pali Rohár
pali.rohar <at> gmail.com
Lv Zheng | 27 Nov 07:25 2014
Picon

[PATCH 0/6] ACPICA: 20141107 Release

The 20141107 ACPICA kernel-resident subsystem updates are linuxized based
on the pm/linux-next branch to form this patchset.

The patchset has passed the following build/boot tests.
Build tests are performed as follows:
1. i386 + default + COFNIG_ACPI=y
2. i386 + allyes + CONFIG_ACPI=y
3. i386 + default + COFNIG_ACPI=n
4. i386 + allyes + CONFIG_ACPI=n
5. x86_64 + default + COFNIG_ACPI=y
6. x86_64 + allyes + CONFIG_ACPI=y
7. x86_64 + default + COFNIG_ACPI=n
8. x86_64 + allyes + CONFIG_ACPI=n
Boot tests are performed as follows:
1. i386 + default + COFNIG_ACPI=y
2. x86_64 + default + COFNIG_ACPI=y
Where:
1. i386: machine named as "Dell Inspiron Mini 1010"
2. x86_64: machine named as "HP Compaq 8200 Elite SFF PC"
3. default: kernel configuration with following items enabled:
   All hardware drivers related to the machines of i386/x86_64
   All drivers/acpi configurations
   All platform drivers

The divergences checking result:
Before applying (20140926 Release):
  852 lines
After applying (20141107 Release):
  852 lines

(Continue reading)

Hanjun Guo | 27 Nov 06:07 2014

[PATCH v2 0/3] cleanups for converting apic_id to phys_id to make it arch agnostic

Some cleanups to convert apic_id to phys_id to accommodate
ACPI 5.0+.

updates since v1:
 - rebase on top of linux-next git repo to slove the conflicts
   with IOAPIC hotplug patch
 - modify patch 2 to update the comments and print message using
   arch independent words instead of APIC

Hanjun Guo (3):
  ACPI / processor: Update the comments in processor.h
  ACPI / processor: Convert apic_id to phys_id to make it arch agnostic
  ACPI / processor: Rename acpi_(un)map_lsapic() to acpi_(un)map_cpu()

 arch/ia64/kernel/acpi.c       |  9 ++++---
 arch/x86/kernel/acpi/boot.c   |  9 ++++---
 drivers/acpi/acpi_processor.c | 25 ++++++++++---------
 drivers/acpi/processor_core.c | 56 +++++++++++++++++++++----------------------
 include/acpi/processor.h      | 12 ++++++----
 include/linux/acpi.h          |  4 ++--
 6 files changed, 59 insertions(+), 56 deletions(-)

--

-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

(Continue reading)

Hanjun Guo | 26 Nov 15:01 2014

[PATCH 1/2] ACPI / table: Add new function to get table entries

From: Ashwin Chaugule <ashwin.chaugule <at> linaro.org>

The acpi_table_parse() function has a callback that
passes a pointer to a table_header. Add a new function
which takes this pointer and parses its entries. This
eliminates the need to re-traverse all the tables for
each call. e.g. as in acpi_table_parse_madt() which is
normally called after acpi_table_parse().

Acked-by: Grant Likely <grant.likely <at> linaro.org>
Signed-off-by: Ashwin Chaugule <ashwin.chaugule <at> linaro.org>
Signed-off-by: Tomasz Nowicki <tomasz.nowicki <at> linaro.org>
Signed-off-by: Hanjun Guo <hanjun.guo <at> linaro.org>
---
 drivers/acpi/tables.c | 63 +++++++++++++++++++++++++++++++++++----------------
 include/linux/acpi.h  |  4 ++++
 2 files changed, 48 insertions(+), 19 deletions(-)

diff --git a/drivers/acpi/tables.c b/drivers/acpi/tables.c
index 6d5a6cd..f1debe9 100644
--- a/drivers/acpi/tables.c
+++ b/drivers/acpi/tables.c
 <at>  <at>  -190,30 +190,24  <at>  <at>  void acpi_table_print_madt_entry(struct acpi_subtable_header *header)
 	}
 }

-
 int __init
-acpi_table_parse_entries(char *id,
-			     unsigned long table_size,
(Continue reading)

Jiang Liu | 26 Nov 03:22 2014
Picon

[Patch Part3 v4] x86, PCI, MSI: Use hierarchy irqdomain to manage MSI interrupts

Enhance MSI code to support hierarchy irqdomain, it helps to make
the architecture more clear.

Signed-off-by: Jiang Liu <jiang.liu <at> linux.intel.com>
---
Hi Thomas,
	Sorry, my branch hasn't been updated to the latest tip/x86/apic
branch. With this patch rebased, all following patches should apply
cleanly without conflicts.
Regards!
Gerry
---
 arch/x86/Kconfig                     |    1 +
 arch/x86/include/asm/hw_irq.h        |    9 ++-
 arch/x86/include/asm/irq_remapping.h |    6 +-
 arch/x86/include/asm/msi.h           |    7 ++
 arch/x86/kernel/apic/msi.c           |  141 ++++++++++++++++++----------------
 arch/x86/kernel/apic/vector.c        |    2 +
 drivers/iommu/irq_remapping.c        |    1 -
 7 files changed, 94 insertions(+), 73 deletions(-)
 create mode 100644 arch/x86/include/asm/msi.h

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 14385ebfd560..e05be74d713d 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
 <at>  <at>  -883,6 +883,7  <at>  <at>  config X86_LOCAL_APIC
 	depends on X86_64 || SMP || X86_32_NON_STANDARD || X86_UP_APIC || PCI_MSI
 	select GENERIC_IRQ_LEGACY_ALLOC_HWIRQ
 	select IRQ_DOMAIN_HIERARCHY
(Continue reading)

Sudeep Holla | 25 Nov 15:48 2014

[PATCH 0/3] ACPI/processor: trivial fixes

Hi Rafael,

While trying to understand the existing ACPI cpuidle driver, I found
few trivial issues. I am not sure if they were left intentionally or
unnoticed as they might not trigger any issues.

Let me know if these makes sense.

Regards,
Sudeep

Sudeep Holla (3):
  ACPI / processor: remove incorrect comparison of phys_id
  ACPI / processor: remove unused variabled from acpi_processor_power
    structure
  ACPI / cpuidle: avoid assigning signed errno to acpi_status

 drivers/acpi/acpi_processor.c |  3 ---
 drivers/acpi/processor_idle.c | 14 +++++++-------
 include/acpi/processor.h      |  3 ---
 3 files changed, 7 insertions(+), 13 deletions(-)

--

-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

(Continue reading)

Jiang Liu | 25 Nov 08:49 2014
Picon

[Patch Part3 v4 00/38] Enable hierarchy irqdomian on x86 platforms

This is the last part to enable support of hierarchy domain on x86
platforms.

It first converts IOAPIC to support hierarchy irqdomain, then cleans
up all unused code and interfaces. It also introduces a kernel boot
parameter to configure CPU vector allocation policies.

It's based on my previous patch set at:
http://lkml.org/lkml/2014/11/25/10
And you may access it at:
https://github.com/jiangliu/linux.git irqdomain/p3v4

It has been tested on Intel 64-bit server and 32-bit laptop. Joerg has
helped to test on AMD platforms. It also passes Fengguang's 0day tests.
Helps are welcomed for testing:
1) Intel MID platform
2) Intel CE or OLPC platforms

Patch 1-3 kills pre_init_apic_IRQ0().
Patch 4-9 convert IOAPIC to use hierarch irqdomain
Patch 10-36 clean up code, unused interfaces etc.
Patch 37-38 introduces a mechanism to configure CPU vector allocation
	policies.

V3->V4:
1) Rebase onto latest prerequisition patch sets

Jiang Liu (37):
  x86, intel-mid, trivial: Refine code syntax for sfi_parse_mtmr()
  x86, irq: Kill unused pre_init_apic_IRQ0()
(Continue reading)

Picon

Information needed


Good day

These are Skipton Financial Services, today we offer loans at interest rate of 3%, our type of loan are: -
business loans, inter company loans individuals loans and family loans. If you have interest in our loan
offer please fill out the form below.

Borrowers name in Full:
Amount Needed as Loan:
The purpose of the loan:
Loan Duration:
Phone:
gender:

We await your prompt response if you need financial assistance.

      E-mail: skipton_fin-services <at> hotmail.com

      Thank you,
      Fulfill your financial needs is our goal!
      Rebecca Allso

--

-- 
Esta mensagem foi verificada pelo sistema de antivirus e
 acredita-se estar livre de perigo.

--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
(Continue reading)

Jiang Liu | 25 Nov 06:53 2014
Picon

[Patch Part2 v6 00/27] Enable hierarchy irqdomian on x86 platforms

We plan to restructure x86 interrupt code based on hierarchy irqdomain,
that is to build irqdomains for CPU vector, interrupt remapping unit,
IOAPIC, MSI and HPET etc and organize those irqdomains in hierarchy mode.
Each irqdomain manages corresponding interrupt controller and talks to
parent interrupt controller through public irqdomain interfaces. We also
support stacked irq_chip based on hierarchy irqdomain. It will make the
x86 interrupt architecture much more clear and more easy to maintain
with hierarchy irqdomain and stacked irq_chip.

This is the second patch set to enable support of hierarchy irqdomain
on x86 platforms. It's based on tip/x86/apic branch and IOMMU x86/vt-d
branch at:
https://git.kernel.org/cgit/linux/kernel/git/joro/iommu.git/ x86/vt-d

You may access it at:
https://github.com/jiangliu/linux.git irqdomain/p2v6

There will aslo be a third patch set to convert IOAPIC driver to support
hierarchy irqdomain and clean up code.

We have tested this patchset on Intel 32-bit and 64-bit systems. Joerg has
helped to test it on AMD platforms. It also passes Fengguang's 0day tests.
Helps are still needed for testings on:
1) AMD HT_IRQ
2) UV platform
3) Intel MID platforms

Patch 1-7 introduce vector domain to manage CPU vectors and convert
	PCI MSI/HPET/DMAT etc to use vector domain.
Patch 8-11 introduce new irq_remapping interfaces to support hierarchy
(Continue reading)

Zheng, Lv | 24 Nov 03:47 2014
Picon

RE: [UPDATE RFC PATCH 2] ACPICA: Events: Introduce ACPI_GPE_HANDLER_RAW to fix 2 issues for the current GPE APIs.

Hi,

Adding people that were disturbed by my fault previously.

You should also reply in the same thread with this validation result.
As we might need this to be the motivation for the proposal that the GPE dead lock issue should be fixed in a
higher priority way.
I've reported this at:
https://bugs.acpica.org/show_bug.cgi?id=1100

Thanks and best regards
-Lv

> From: Kirill A. Shutemov [mailto:kirill <at> shutemov.name]
> Sent: Friday, November 21, 2014 8:41 PM
> 
> On Fri, Nov 21, 2014 at 01:05:40AM +0000, Zheng, Lv wrote:
> > Hi, Kirill
> >
> > Please help to check again to use the updated patch.
> > Sorry for my mistake.
> >
> > I originally used a patch that will unlock before invoking all handlers.
> > But as requested by maintainers, the new ACPICA part will use a ACPI_GPE_HANDLER_RAW flag, and I updated
my patch in a hurry
> for you without updating the ec.c.
> >
> > It's my fault.
> > I can also do some local confirmation before disturbing you.
> > Could you tell me how can I reproduce this?
(Continue reading)

Lv Zheng | 21 Nov 01:57 2014
Picon

[UPDATE RFC PATCH 2] ACPICA: Events: Introduce ACPI_GPE_HANDLER_RAW to fix 2 issues for the current GPE APIs.

(update due to a missing flag set in ec.c)

Since whether the GPE should be disabled/enabled/cleared should only be
determined by the GPE driver's state machine:
1. GPE should be disabled if the driver wants to switch to the GPE polling
   mode when a GPE storm condition is indicated and should be enabled if
   the driver wants to switch back to the GPE interrupt mode when all of
   the storm conditions are cleared. The conditions should be protected by
   the driver's specific lock.
2. GPE should be enabled if the driver has accepted more than one request
   and should be disabled if the driver has completed all of the requests.
   The request count should be protected by the driver's specific lock.
3. GPE should be cleared either when the driver is about to handle an edge
   triggered GPE or when the driver has completed to handle a level
   triggered GPE. The handling code should be protected by the driver's
   specific lock.
Thus the GPE enabling/disabling/clearing operations are likely to be
performed with the driver's specific lock held while we currently cannot do
this. This is because:
1. We have the acpi_gbl_gpe_lock held before invoking the GPE driver's
   handler. Driver's specific lock is likely to be held inside of the
   handler, thus we can see some dead lock issues due to the reversed
   locking order or recursive locking. In order to solve such dead lock
   issues, we need to unlock the acpi_gbl_gpe_lock before invoking the
   handler. BZ 1100.
2. Since GPE disabling/enabling/clearing should be determined by the GPE
   driver's state machine, we shouldn't perform such operations inside of
   ACPICA for a GPE handler to mess up the driver's state machine. BZ 1101.
Originally this patch includes a logic to flush GPE handlers, it is dropped
due to the following reasons:
(Continue reading)


Gmane