[no subject]
$1,000,000.00 dollars has been donated to you by Maureen David Kaltschmidt who won the Powerball Jackpot of $758.7 million Dollars. Contact her via Email: maureendavidkaltschmidt...@gmail.com for more details
[no subject]
I have a charity mission worth $ 100,000,000.00 from you
[no subject]
good day I sent you a letter a month ago, but I not sure what his email quickly, My name is Veronica Ali. a France Nationality, I am a widow, currently hospitalized due to cancer illness . Meanwhile, I have decided to donate my fund to you as a reliable individual that will use this money wisely, €3,800.000 Million Euros. to help the poor and less privileged. So if you are willing to accept this offer and do exactly as I will instruct, then get back to me for more details. Mrs Veronica Ali.
[no subject]
subscribe linux-kernel
[no subject]
subscribe linux-rt-users
Re: Subject: [PATCH v4 0/4] mtd: rawnand: ams-delta: Use GPIO API for data I/O
* Miquel Raynal [181207 08:04]:
> Hi Tony,
>
> Tony Lindgren wrote on Fri, 23 Nov 2018 09:03:33
> -0800:
>
> > * Boris Brezillon [181121 14:56]:
> > > On Wed, 21 Nov 2018 12:08:02 +0100
> > > Janusz Krzysztofik wrote:
> > >
> > > > Finalize implementation of the idea suggested by Artem Bityutskiy and
> > > > Tony Lindgren, described in commit b027274d2e3a ("mtd: ams-delta: fix
> > > > request_mem_region() failure"). Use pure GPIO consumer API, as reqested
> > > > by Boris Brezillon.
> > > >
> > > > Janusz Krzysztofik (4):
> > > > ARM: OMAP1: ams-delta: Provide GPIO lookup table for NAND data
> > > > port
> > > > mtd: rawnand: ams-delta: Request data port GPIO resource
> > > > mtd: rawnand: ams-delta: Use GPIO API for data I/O
> > > > ARM: OMAP1: ams-delta: Drop obsolete NAND resources
> > > >
> > > > arch/arm/mach-omap1/board-ams-delta.c | 22 ++
> > > > drivers/mtd/nand/raw/ams-delta.c | 120
> > > > +++---
> > > > 2 files changed, 80 insertions(+), 62 deletions(-)
> > > >
> > > > Performance on Amstrad Delta is now acceptable after recent extensions
> > > > to GPIO API and rawnanad enhancements.
> > > >
> > > > Series intented to be merged via mtd tree, should not conflict with
> > > > other OMAP1 patches submitted for 4.21.
> > >
> > > We'll prepare an immutable tag, just in case.
> >
> > Sounds good to me thanks:
> >
> > Acked-by: Tony Lindgren
>
> Actually, I can't setup a topic branch with this series because it
> depends on other changes in nand/next. If a conflict happens in -next,
> I suppose we will have to send you a PR.
Hmm OK I have pretty much all the stuff applied and in next
already so if it's not conflicting now it should not conflict.
Regards,
Tony
Re: Subject: [PATCH v4 0/4] mtd: rawnand: ams-delta: Use GPIO API for data I/O
* Miquel Raynal [181207 08:04]:
> Hi Tony,
>
> Tony Lindgren wrote on Fri, 23 Nov 2018 09:03:33
> -0800:
>
> > * Boris Brezillon [181121 14:56]:
> > > On Wed, 21 Nov 2018 12:08:02 +0100
> > > Janusz Krzysztofik wrote:
> > >
> > > > Finalize implementation of the idea suggested by Artem Bityutskiy and
> > > > Tony Lindgren, described in commit b027274d2e3a ("mtd: ams-delta: fix
> > > > request_mem_region() failure"). Use pure GPIO consumer API, as reqested
> > > > by Boris Brezillon.
> > > >
> > > > Janusz Krzysztofik (4):
> > > > ARM: OMAP1: ams-delta: Provide GPIO lookup table for NAND data
> > > > port
> > > > mtd: rawnand: ams-delta: Request data port GPIO resource
> > > > mtd: rawnand: ams-delta: Use GPIO API for data I/O
> > > > ARM: OMAP1: ams-delta: Drop obsolete NAND resources
> > > >
> > > > arch/arm/mach-omap1/board-ams-delta.c | 22 ++
> > > > drivers/mtd/nand/raw/ams-delta.c | 120
> > > > +++---
> > > > 2 files changed, 80 insertions(+), 62 deletions(-)
> > > >
> > > > Performance on Amstrad Delta is now acceptable after recent extensions
> > > > to GPIO API and rawnanad enhancements.
> > > >
> > > > Series intented to be merged via mtd tree, should not conflict with
> > > > other OMAP1 patches submitted for 4.21.
> > >
> > > We'll prepare an immutable tag, just in case.
> >
> > Sounds good to me thanks:
> >
> > Acked-by: Tony Lindgren
>
> Actually, I can't setup a topic branch with this series because it
> depends on other changes in nand/next. If a conflict happens in -next,
> I suppose we will have to send you a PR.
Hmm OK I have pretty much all the stuff applied and in next
already so if it's not conflicting now it should not conflict.
Regards,
Tony
Re: Subject: [PATCH v4 0/4] mtd: rawnand: ams-delta: Use GPIO API for data I/O
Hi Tony,
Tony Lindgren wrote on Fri, 23 Nov 2018 09:03:33
-0800:
> * Boris Brezillon [181121 14:56]:
> > On Wed, 21 Nov 2018 12:08:02 +0100
> > Janusz Krzysztofik wrote:
> >
> > > Finalize implementation of the idea suggested by Artem Bityutskiy and
> > > Tony Lindgren, described in commit b027274d2e3a ("mtd: ams-delta: fix
> > > request_mem_region() failure"). Use pure GPIO consumer API, as reqested
> > > by Boris Brezillon.
> > >
> > > Janusz Krzysztofik (4):
> > > ARM: OMAP1: ams-delta: Provide GPIO lookup table for NAND data port
> > > mtd: rawnand: ams-delta: Request data port GPIO resource
> > > mtd: rawnand: ams-delta: Use GPIO API for data I/O
> > > ARM: OMAP1: ams-delta: Drop obsolete NAND resources
> > >
> > > arch/arm/mach-omap1/board-ams-delta.c | 22 ++
> > > drivers/mtd/nand/raw/ams-delta.c | 120
> > > +++---
> > > 2 files changed, 80 insertions(+), 62 deletions(-)
> > >
> > > Performance on Amstrad Delta is now acceptable after recent extensions
> > > to GPIO API and rawnanad enhancements.
> > >
> > > Series intented to be merged via mtd tree, should not conflict with
> > > other OMAP1 patches submitted for 4.21.
> >
> > We'll prepare an immutable tag, just in case.
>
> Sounds good to me thanks:
>
> Acked-by: Tony Lindgren
Actually, I can't setup a topic branch with this series because it
depends on other changes in nand/next. If a conflict happens in -next,
I suppose we will have to send you a PR.
Thanks,
Miquèl
Re: Subject: [PATCH v4 0/4] mtd: rawnand: ams-delta: Use GPIO API for data I/O
Hi Tony,
Tony Lindgren wrote on Fri, 23 Nov 2018 09:03:33
-0800:
> * Boris Brezillon [181121 14:56]:
> > On Wed, 21 Nov 2018 12:08:02 +0100
> > Janusz Krzysztofik wrote:
> >
> > > Finalize implementation of the idea suggested by Artem Bityutskiy and
> > > Tony Lindgren, described in commit b027274d2e3a ("mtd: ams-delta: fix
> > > request_mem_region() failure"). Use pure GPIO consumer API, as reqested
> > > by Boris Brezillon.
> > >
> > > Janusz Krzysztofik (4):
> > > ARM: OMAP1: ams-delta: Provide GPIO lookup table for NAND data port
> > > mtd: rawnand: ams-delta: Request data port GPIO resource
> > > mtd: rawnand: ams-delta: Use GPIO API for data I/O
> > > ARM: OMAP1: ams-delta: Drop obsolete NAND resources
> > >
> > > arch/arm/mach-omap1/board-ams-delta.c | 22 ++
> > > drivers/mtd/nand/raw/ams-delta.c | 120
> > > +++---
> > > 2 files changed, 80 insertions(+), 62 deletions(-)
> > >
> > > Performance on Amstrad Delta is now acceptable after recent extensions
> > > to GPIO API and rawnanad enhancements.
> > >
> > > Series intented to be merged via mtd tree, should not conflict with
> > > other OMAP1 patches submitted for 4.21.
> >
> > We'll prepare an immutable tag, just in case.
>
> Sounds good to me thanks:
>
> Acked-by: Tony Lindgren
Actually, I can't setup a topic branch with this series because it
depends on other changes in nand/next. If a conflict happens in -next,
I suppose we will have to send you a PR.
Thanks,
Miquèl
[no subject]
Dzień dobry, miło cię poznać, proszę, napisz do mnie, mam coś, co chcę z tobą omówić dzięki
[no subject]
Dzień dobry, miło cię poznać, proszę, napisz do mnie, mam coś, co chcę z tobą omówić dzięki
[no subject]
-- Good day, I am Mrs Ulrica Mica from Hungary but based in the United Kindom, i am hospitalized in London suffering from Acute Cancer.i want to sign a Donation of $6,800,000 Usd on orphans in your area,can you handle it?, because of the confidentiality of the subject, Please contact me back directly on this my email (ulrica.mi...@aol.com), I have sent this proposal several times without receiving any response from you, Your responds on my private email address will determined how serious you are. I am making this donation because my doctor have issued to me that the rate of the cancer that i have just some days to live. There i decided to donate all that i have to the orphans. Mrs Ulrica Mica London. United Kingdom
[no subject]
-- Good day, I am Mrs Ulrica Mica from Hungary but based in the United Kindom, i am hospitalized in London suffering from Acute Cancer.i want to sign a Donation of $6,800,000 Usd on orphans in your area,can you handle it?, because of the confidentiality of the subject, Please contact me back directly on this my email (ulrica.mi...@aol.com), I have sent this proposal several times without receiving any response from you, Your responds on my private email address will determined how serious you are. I am making this donation because my doctor have issued to me that the rate of the cancer that i have just some days to live. There i decided to donate all that i have to the orphans. Mrs Ulrica Mica London. United Kingdom
[no subject]
-- Guten Tag, Wir sind eine registrierte private Geldverleiher. Wir geben Kredite an Firmen, Einzelpersonen, die ihre finanzielle Status auf der ganzen Welt aktualisieren müssen, mit minimalen jährlichen Zinsen von 2% .reply, wenn nötig. Good Day, We are a registered private money lender. We give out loans to firms, Individual who need to update their financial status all over the world, with Minimal annual Interest Rates of 2%reply if needed.
[no subject]
-- Guten Tag, Wir sind eine registrierte private Geldverleiher. Wir geben Kredite an Firmen, Einzelpersonen, die ihre finanzielle Status auf der ganzen Welt aktualisieren müssen, mit minimalen jährlichen Zinsen von 2% .reply, wenn nötig. Good Day, We are a registered private money lender. We give out loans to firms, Individual who need to update their financial status all over the world, with Minimal annual Interest Rates of 2%reply if needed.
Re: Subject: [PATCH v4 0/4] mtd: rawnand: ams-delta: Use GPIO API for data I/O
* Boris Brezillon [181121 14:56]:
> On Wed, 21 Nov 2018 12:08:02 +0100
> Janusz Krzysztofik wrote:
>
> > Finalize implementation of the idea suggested by Artem Bityutskiy and
> > Tony Lindgren, described in commit b027274d2e3a ("mtd: ams-delta: fix
> > request_mem_region() failure"). Use pure GPIO consumer API, as reqested
> > by Boris Brezillon.
> >
> > Janusz Krzysztofik (4):
> > ARM: OMAP1: ams-delta: Provide GPIO lookup table for NAND data port
> > mtd: rawnand: ams-delta: Request data port GPIO resource
> > mtd: rawnand: ams-delta: Use GPIO API for data I/O
> > ARM: OMAP1: ams-delta: Drop obsolete NAND resources
> >
> > arch/arm/mach-omap1/board-ams-delta.c | 22 ++
> > drivers/mtd/nand/raw/ams-delta.c | 120
> > +++---
> > 2 files changed, 80 insertions(+), 62 deletions(-)
> >
> > Performance on Amstrad Delta is now acceptable after recent extensions
> > to GPIO API and rawnanad enhancements.
> >
> > Series intented to be merged via mtd tree, should not conflict with
> > other OMAP1 patches submitted for 4.21.
>
> We'll prepare an immutable tag, just in case.
Sounds good to me thanks:
Acked-by: Tony Lindgren
Re: Subject: [PATCH v4 0/4] mtd: rawnand: ams-delta: Use GPIO API for data I/O
* Boris Brezillon [181121 14:56]:
> On Wed, 21 Nov 2018 12:08:02 +0100
> Janusz Krzysztofik wrote:
>
> > Finalize implementation of the idea suggested by Artem Bityutskiy and
> > Tony Lindgren, described in commit b027274d2e3a ("mtd: ams-delta: fix
> > request_mem_region() failure"). Use pure GPIO consumer API, as reqested
> > by Boris Brezillon.
> >
> > Janusz Krzysztofik (4):
> > ARM: OMAP1: ams-delta: Provide GPIO lookup table for NAND data port
> > mtd: rawnand: ams-delta: Request data port GPIO resource
> > mtd: rawnand: ams-delta: Use GPIO API for data I/O
> > ARM: OMAP1: ams-delta: Drop obsolete NAND resources
> >
> > arch/arm/mach-omap1/board-ams-delta.c | 22 ++
> > drivers/mtd/nand/raw/ams-delta.c | 120
> > +++---
> > 2 files changed, 80 insertions(+), 62 deletions(-)
> >
> > Performance on Amstrad Delta is now acceptable after recent extensions
> > to GPIO API and rawnanad enhancements.
> >
> > Series intented to be merged via mtd tree, should not conflict with
> > other OMAP1 patches submitted for 4.21.
>
> We'll prepare an immutable tag, just in case.
Sounds good to me thanks:
Acked-by: Tony Lindgren
Re: Subject: [PATCH v4 0/4] mtd: rawnand: ams-delta: Use GPIO API for data I/O
On Wed, 21 Nov 2018 12:08:02 +0100
Janusz Krzysztofik wrote:
> Finalize implementation of the idea suggested by Artem Bityutskiy and
> Tony Lindgren, described in commit b027274d2e3a ("mtd: ams-delta: fix
> request_mem_region() failure"). Use pure GPIO consumer API, as reqested
> by Boris Brezillon.
>
> Janusz Krzysztofik (4):
> ARM: OMAP1: ams-delta: Provide GPIO lookup table for NAND data port
> mtd: rawnand: ams-delta: Request data port GPIO resource
> mtd: rawnand: ams-delta: Use GPIO API for data I/O
> ARM: OMAP1: ams-delta: Drop obsolete NAND resources
>
> arch/arm/mach-omap1/board-ams-delta.c | 22 ++
> drivers/mtd/nand/raw/ams-delta.c | 120
> +++---
> 2 files changed, 80 insertions(+), 62 deletions(-)
>
> Performance on Amstrad Delta is now acceptable after recent extensions
> to GPIO API and rawnanad enhancements.
>
> Series intented to be merged via mtd tree, should not conflict with
> other OMAP1 patches submitted for 4.21.
We'll prepare an immutable tag, just in case.
Re: Subject: [PATCH v4 0/4] mtd: rawnand: ams-delta: Use GPIO API for data I/O
On Wed, 21 Nov 2018 12:08:02 +0100
Janusz Krzysztofik wrote:
> Finalize implementation of the idea suggested by Artem Bityutskiy and
> Tony Lindgren, described in commit b027274d2e3a ("mtd: ams-delta: fix
> request_mem_region() failure"). Use pure GPIO consumer API, as reqested
> by Boris Brezillon.
>
> Janusz Krzysztofik (4):
> ARM: OMAP1: ams-delta: Provide GPIO lookup table for NAND data port
> mtd: rawnand: ams-delta: Request data port GPIO resource
> mtd: rawnand: ams-delta: Use GPIO API for data I/O
> ARM: OMAP1: ams-delta: Drop obsolete NAND resources
>
> arch/arm/mach-omap1/board-ams-delta.c | 22 ++
> drivers/mtd/nand/raw/ams-delta.c | 120
> +++---
> 2 files changed, 80 insertions(+), 62 deletions(-)
>
> Performance on Amstrad Delta is now acceptable after recent extensions
> to GPIO API and rawnanad enhancements.
>
> Series intented to be merged via mtd tree, should not conflict with
> other OMAP1 patches submitted for 4.21.
We'll prepare an immutable tag, just in case.
Subject: [PATCH v4 0/4] mtd: rawnand: ams-delta: Use GPIO API for data I/O
Finalize implementation of the idea suggested by Artem Bityutskiy and
Tony Lindgren, described in commit b027274d2e3a ("mtd: ams-delta: fix
request_mem_region() failure"). Use pure GPIO consumer API, as reqested
by Boris Brezillon.
Janusz Krzysztofik (4):
ARM: OMAP1: ams-delta: Provide GPIO lookup table for NAND data port
mtd: rawnand: ams-delta: Request data port GPIO resource
mtd: rawnand: ams-delta: Use GPIO API for data I/O
ARM: OMAP1: ams-delta: Drop obsolete NAND resources
arch/arm/mach-omap1/board-ams-delta.c | 22 ++
drivers/mtd/nand/raw/ams-delta.c | 120 +++---
2 files changed, 80 insertions(+), 62 deletions(-)
Performance on Amstrad Delta is now acceptable after recent extensions
to GPIO API and rawnanad enhancements.
Series intented to be merged via mtd tree, should not conflict with
other OMAP1 patches submitted for 4.21.
Changelog:
v4:
- drop patches 1/7, 2/7, 5/7 6/7 - changes already merged,
- reintroduce postponed PATCH v2 06/12 as 4/4,
- rebase on nand-next for 4.21.
v3:
[PATCH v3 1/7] mtd: rawnand: ams-delta: show parent device in sysfs
- renamed and an explanation added based on other similar patches on
Marek Vasut request, thanks.
[PATCH v3 2/7] mtd: rawnand: ams-delta: Use private structure
- no changes.
[PATCH v3 3/7] ARM: OMAP1: ams-delta: Provide GPIO lookup table for NAND
data port
- no changes.
[PATCH v3 4/7] mtd: rawnand: ams-delta: request data port GPIO resource
- no changes.
[PATCH v3 5/7] mtd: rawnand: ams-delta: Set port direction when needed
- modified to set port direction only when needed instead of on each
transfer as suggested by Boris, thanks, though I kept separate
*_next_byte() functions to maximize performance as much as possible,
- moved back in front of "mtd: rawnand: ams-delta: use GPIO API for data
I/O" with a comment added referring to the planned switch to GPIO API.
[PATCH v3 6/7] mtd: rawnand: ams-delta: Simplify pointer resolution
- moved back in front of "mtd: rawnand: ams-delta: use GPIO API for data
I/O" on Boris request, thanks.
[RFC PATCH v3 7/7] mtd: rawnand: ams-delta: use GPIO API for data I/O
- rebased back on top of the two mentioned above,
- not intended to apply it yet due to performance issues on Amstrad Delta.
Removed from the series:
[RFC PATCH v2 09/12] gpiolib: Identify GPIO descriptor arrays with direct
mapping
[RFC PATCH v2 10/12] gpiolib: Introduce bitmap get/set array API extension
[RFC PATCH v2 11/12] mtd: rawnand: ams-delta: Use GPIO API bitmap extension
[RFC PATCH v2 12/12] gpiolib: Add fast processing path to bitmap API functions
- intended to be still iterated in a follow up series until performance
issues are resolved.
[RFC PATCH v2 06/12] ARM: OMAP1: ams-delta: drop obsolete NAND resources
- postponed until acceptable performance on Amstrad Delta is achieved.
v2:
[RFC PATCH v2 00/12] mtd: rawnand: ams-delta: Use GPIO API for data I/O
- renamed from former [RFC PATCH 0/8] mtd: rawnand: ams-delta: Use
gpio-omap accessors for data I/O
[RFC PATCH v2 01/12] mtd: rawnand: ams-delta: Assign mtd->dev.parent,
not mtd->owner
- split out from former [RFC PATCH 1/8] on Boris request, thanks.
[RFC PATCH v2 02/12] mtd: rawnand: ams-delta: Use private structure
- remaining part of the former [RFC PATCH 1/8].
[RFC PATCH v2 03/12] ARM: OMAP1: ams-delta: Provide GPIO lookup table
for NAND data port
- split out from former [RFC PATCH 5/8] on Boris requesst, thanks,
[RFC PATCH v2 04/12] mtd: rawnand: ams-delta: request data port GPIO resource
- remaining part of the former [RFC PATCH 5/8],
[RFC PATCH v2 05/12] mtd: rawnand: ams-delta: use GPIO API for data read/write
- reworked from former [RFC PATCH 8/8] on Boris requesst to use pure
GPIO API, thanks,
- moved up in front of former [RFC PATCH 3/8] on Boris request, thanks.
[RFC PATCH v2 06/12] ARM: OMAP1: ams-delta: drop obsolete NAND resources
- split out from former [RFC PATCH 8/8].
[RFC PATCH v2 07/12] mtd: rawnand: ams-delta: Set port direction once per
transfer
- reworked from former [RFC PATCH 3/8] on top of [RFC PATCH v2 05/12].
[RFC PATCH v2 08/12] mtd: rawnand: ams-delta: Simplify pointer resolution
on read/write
- reworked from former [RFC PATCH 4/8] on top of [RFC PATCH v2 08/12],
- renamed from 'Optimize' to 'Simplify' on Boris request, thanks.
[RFC PATCH v2 09/12] gpiolib: Identify GPIO descriptor arrays with direct
mapping
- new patch.
[RFC PATCH v2 10/12] gpiolib: Introduce bitmap get/set array API extension
- new patch.
[RFC PATCH v2 11/12] mtd: rawnand: ams-delta: Use GPIO API bitmap extension
- new patch.
[RFC PATCH v2 12/12] gpiolib: Add fast processing path to bitmap API functions
- new patch.
Removed from the series:
[RFC PATCH 2/8] mtd: rawnand: ams-delta: Write protect device during probe
- postponed on Boris request, thanks.
[RFC PATCH 6/8] gpio: omap: Add
Subject: [PATCH v4 0/4] mtd: rawnand: ams-delta: Use GPIO API for data I/O
Finalize implementation of the idea suggested by Artem Bityutskiy and
Tony Lindgren, described in commit b027274d2e3a ("mtd: ams-delta: fix
request_mem_region() failure"). Use pure GPIO consumer API, as reqested
by Boris Brezillon.
Janusz Krzysztofik (4):
ARM: OMAP1: ams-delta: Provide GPIO lookup table for NAND data port
mtd: rawnand: ams-delta: Request data port GPIO resource
mtd: rawnand: ams-delta: Use GPIO API for data I/O
ARM: OMAP1: ams-delta: Drop obsolete NAND resources
arch/arm/mach-omap1/board-ams-delta.c | 22 ++
drivers/mtd/nand/raw/ams-delta.c | 120 +++---
2 files changed, 80 insertions(+), 62 deletions(-)
Performance on Amstrad Delta is now acceptable after recent extensions
to GPIO API and rawnanad enhancements.
Series intented to be merged via mtd tree, should not conflict with
other OMAP1 patches submitted for 4.21.
Changelog:
v4:
- drop patches 1/7, 2/7, 5/7 6/7 - changes already merged,
- reintroduce postponed PATCH v2 06/12 as 4/4,
- rebase on nand-next for 4.21.
v3:
[PATCH v3 1/7] mtd: rawnand: ams-delta: show parent device in sysfs
- renamed and an explanation added based on other similar patches on
Marek Vasut request, thanks.
[PATCH v3 2/7] mtd: rawnand: ams-delta: Use private structure
- no changes.
[PATCH v3 3/7] ARM: OMAP1: ams-delta: Provide GPIO lookup table for NAND
data port
- no changes.
[PATCH v3 4/7] mtd: rawnand: ams-delta: request data port GPIO resource
- no changes.
[PATCH v3 5/7] mtd: rawnand: ams-delta: Set port direction when needed
- modified to set port direction only when needed instead of on each
transfer as suggested by Boris, thanks, though I kept separate
*_next_byte() functions to maximize performance as much as possible,
- moved back in front of "mtd: rawnand: ams-delta: use GPIO API for data
I/O" with a comment added referring to the planned switch to GPIO API.
[PATCH v3 6/7] mtd: rawnand: ams-delta: Simplify pointer resolution
- moved back in front of "mtd: rawnand: ams-delta: use GPIO API for data
I/O" on Boris request, thanks.
[RFC PATCH v3 7/7] mtd: rawnand: ams-delta: use GPIO API for data I/O
- rebased back on top of the two mentioned above,
- not intended to apply it yet due to performance issues on Amstrad Delta.
Removed from the series:
[RFC PATCH v2 09/12] gpiolib: Identify GPIO descriptor arrays with direct
mapping
[RFC PATCH v2 10/12] gpiolib: Introduce bitmap get/set array API extension
[RFC PATCH v2 11/12] mtd: rawnand: ams-delta: Use GPIO API bitmap extension
[RFC PATCH v2 12/12] gpiolib: Add fast processing path to bitmap API functions
- intended to be still iterated in a follow up series until performance
issues are resolved.
[RFC PATCH v2 06/12] ARM: OMAP1: ams-delta: drop obsolete NAND resources
- postponed until acceptable performance on Amstrad Delta is achieved.
v2:
[RFC PATCH v2 00/12] mtd: rawnand: ams-delta: Use GPIO API for data I/O
- renamed from former [RFC PATCH 0/8] mtd: rawnand: ams-delta: Use
gpio-omap accessors for data I/O
[RFC PATCH v2 01/12] mtd: rawnand: ams-delta: Assign mtd->dev.parent,
not mtd->owner
- split out from former [RFC PATCH 1/8] on Boris request, thanks.
[RFC PATCH v2 02/12] mtd: rawnand: ams-delta: Use private structure
- remaining part of the former [RFC PATCH 1/8].
[RFC PATCH v2 03/12] ARM: OMAP1: ams-delta: Provide GPIO lookup table
for NAND data port
- split out from former [RFC PATCH 5/8] on Boris requesst, thanks,
[RFC PATCH v2 04/12] mtd: rawnand: ams-delta: request data port GPIO resource
- remaining part of the former [RFC PATCH 5/8],
[RFC PATCH v2 05/12] mtd: rawnand: ams-delta: use GPIO API for data read/write
- reworked from former [RFC PATCH 8/8] on Boris requesst to use pure
GPIO API, thanks,
- moved up in front of former [RFC PATCH 3/8] on Boris request, thanks.
[RFC PATCH v2 06/12] ARM: OMAP1: ams-delta: drop obsolete NAND resources
- split out from former [RFC PATCH 8/8].
[RFC PATCH v2 07/12] mtd: rawnand: ams-delta: Set port direction once per
transfer
- reworked from former [RFC PATCH 3/8] on top of [RFC PATCH v2 05/12].
[RFC PATCH v2 08/12] mtd: rawnand: ams-delta: Simplify pointer resolution
on read/write
- reworked from former [RFC PATCH 4/8] on top of [RFC PATCH v2 08/12],
- renamed from 'Optimize' to 'Simplify' on Boris request, thanks.
[RFC PATCH v2 09/12] gpiolib: Identify GPIO descriptor arrays with direct
mapping
- new patch.
[RFC PATCH v2 10/12] gpiolib: Introduce bitmap get/set array API extension
- new patch.
[RFC PATCH v2 11/12] mtd: rawnand: ams-delta: Use GPIO API bitmap extension
- new patch.
[RFC PATCH v2 12/12] gpiolib: Add fast processing path to bitmap API functions
- new patch.
Removed from the series:
[RFC PATCH 2/8] mtd: rawnand: ams-delta: Write protect device during probe
- postponed on Boris request, thanks.
[RFC PATCH 6/8] gpio: omap: Add
[no subject]
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: hornbeckmajordennis...@gmail.com Regards,Major Dennis Hornbeck.
[no subject]
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: hornbeckmajordennis...@gmail.com Regards,Major Dennis Hornbeck.
[no subject]
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: majordennis...@gmail.com Regards,Major Dennis Hornbeck.
[no subject]
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: majordennis...@gmail.com Regards,Major Dennis Hornbeck.
[no subject]
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: majordennis...@gmail.com Regards,Major Dennis Hornbeck.
[no subject]
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: majordennis...@gmail.com Regards,Major Dennis Hornbeck.
[PATCH v3 0/4] Subject: Enable Linux guests on Hyper-V on ARM64
This series enables Linux guests running on Hyper-V on ARM64
hardware. New ARM64-specific code in arch/arm64/hyperv initializes
Hyper-V, including its synthetic clocks and hypercall mechanism.
Existing architecture independent drivers for Hyper-V's VMbus and
synthetic devices just work when built for ARM64. Hyper-V code is
built and included in the image and modules only if CONFIG_HYPERV
is enabled.
The four patches are organized as follows:
1) Add include files that define the Hyper-V interface as
described in the Hyper-V Top Level Functional Spec (TLFS), plus
additional definitions specific to Linux running on Hyper-V.
2) Add core Hyper-V support on ARM64, including hypercalls,
synthetic clock initialization, and interrupt handlers.
3) Update the existing VMbus driver to generalize interrupt
management across x86/x64 and ARM64.
4) Make CONFIG_HYPERV selectable on ARM64 in addition to x86/x64.
Some areas of Linux guests on Hyper-V on ARM64 are a work-
in-progress, primarily due to work still being done in Hyper-V:
* Hyper-V on ARM64 currently runs with a 4 Kbyte page size, and only
supports guests with a 4 Kbyte page size. Because Hyper-V uses
shared pages to communicate between the guest and the hypervisor,
there are open design decisions on the page size to use when
the guest is using 16K/64K pages. Once those issues are
resolved and Hyper-V fully supports 16K/64K guest pages, changes
may be needed in the Linux drivers for Hyper-V synthetic devices.
* Hyper-V on ARM64 does not currently support mapping PCI devices
into the guest address space. The Hyper-V PCI driver at
drivers/pci/host/pci-hyperv.c has x86/x64-specific code and is
not being built for ARM64.
In a few cases, terminology from the x86/x64 world has been carried
over into the ARM64 code ("MSR", "TSC"). Hyper-V still uses the
x86/x64 terminology and has not replaced it with something more
generic, so the code uses the Hyper-V terminology. This will be
fixed when Hyper-V updates the usage in the TLFS.
Changes in v3:
* Added initialization of hv_vp_index array like was recently
added on x86 branch [KY Srinivasan]
* Changed Hyper-V ARM64 register symbols to be all uppercase
instead of mixed case [KY Srinivasan]
* Separated mshyperv.h into two files, one architecture
independent and one architecture dependent. After this code
is upstream, will make changes to the x86 code to use the
architecture independent file and remove duplication. And
once we have a multi-architecture Hyper-V TLFS, will do a
separate patch to split hyperv-tlfs.h in the same way.
[KY Srinivasan]
* Minor tweaks to rebase to latest linux-next code
Changes in v2:
* Removed patch to implement slow_virt_to_phys() on ARM64.
Use of slow_virt_to_phys() in arch independent Hyper-V
drivers has been eliminated by commit 6ba34171bcbd
("Drivers: hv: vmbus: Remove use of slow_virt_to_phys()")
* Minor tweaks to rebase to latest linux-next code
Michael Kelley (4):
arm64: hyperv: Add core Hyper-V include files
arm64: hyperv: Add support for Hyper-V as a hypervisor
Drivers: hv: vmbus: Add hooks for per-CPU IRQ
Drivers: hv: Enable CONFIG_HYPERV on ARM64
MAINTAINERS | 4 +
arch/arm64/Makefile | 1 +
arch/arm64/hyperv/Makefile | 2 +
arch/arm64/hyperv/hv_hvc.S | 54 +
arch/arm64/hyperv/hv_init.c | 441 +++
arch/arm64/hyperv/mshyperv.c | 178 ++
arch/arm64/include/asm/hyperv-tlfs.h | 338 +++
arch/arm64/include/asm/mshyperv.h| 116 +
arch/x86/include/asm/mshyperv.h | 4 +
drivers/hv/Kconfig | 3 +-
drivers/hv/hv.c | 2 +
include/asm-generic/mshyperv.h | 240 +++
12 files changed, 1382 insertions(+), 1 deletion(-)
create mode 100644 arch/arm64/hyperv/Makefile
create mode 100644 arch/arm64/hyperv/hv_hvc.S
create mode 100644 arch/arm64/hyperv/hv_init.c
create mode 100644 arch/arm64/hyperv/mshyperv.c
create mode 100644 arch/arm64/include/asm/hyperv-tlfs.h
create mode 100644 arch/arm64/include/asm/mshyperv.h
create mode 100644 include/asm-generic/mshyperv.h
--
1.8.3.1
[PATCH v3 0/4] Subject: Enable Linux guests on Hyper-V on ARM64
This series enables Linux guests running on Hyper-V on ARM64
hardware. New ARM64-specific code in arch/arm64/hyperv initializes
Hyper-V, including its synthetic clocks and hypercall mechanism.
Existing architecture independent drivers for Hyper-V's VMbus and
synthetic devices just work when built for ARM64. Hyper-V code is
built and included in the image and modules only if CONFIG_HYPERV
is enabled.
The four patches are organized as follows:
1) Add include files that define the Hyper-V interface as
described in the Hyper-V Top Level Functional Spec (TLFS), plus
additional definitions specific to Linux running on Hyper-V.
2) Add core Hyper-V support on ARM64, including hypercalls,
synthetic clock initialization, and interrupt handlers.
3) Update the existing VMbus driver to generalize interrupt
management across x86/x64 and ARM64.
4) Make CONFIG_HYPERV selectable on ARM64 in addition to x86/x64.
Some areas of Linux guests on Hyper-V on ARM64 are a work-
in-progress, primarily due to work still being done in Hyper-V:
* Hyper-V on ARM64 currently runs with a 4 Kbyte page size, and only
supports guests with a 4 Kbyte page size. Because Hyper-V uses
shared pages to communicate between the guest and the hypervisor,
there are open design decisions on the page size to use when
the guest is using 16K/64K pages. Once those issues are
resolved and Hyper-V fully supports 16K/64K guest pages, changes
may be needed in the Linux drivers for Hyper-V synthetic devices.
* Hyper-V on ARM64 does not currently support mapping PCI devices
into the guest address space. The Hyper-V PCI driver at
drivers/pci/host/pci-hyperv.c has x86/x64-specific code and is
not being built for ARM64.
In a few cases, terminology from the x86/x64 world has been carried
over into the ARM64 code ("MSR", "TSC"). Hyper-V still uses the
x86/x64 terminology and has not replaced it with something more
generic, so the code uses the Hyper-V terminology. This will be
fixed when Hyper-V updates the usage in the TLFS.
Changes in v3:
* Added initialization of hv_vp_index array like was recently
added on x86 branch [KY Srinivasan]
* Changed Hyper-V ARM64 register symbols to be all uppercase
instead of mixed case [KY Srinivasan]
* Separated mshyperv.h into two files, one architecture
independent and one architecture dependent. After this code
is upstream, will make changes to the x86 code to use the
architecture independent file and remove duplication. And
once we have a multi-architecture Hyper-V TLFS, will do a
separate patch to split hyperv-tlfs.h in the same way.
[KY Srinivasan]
* Minor tweaks to rebase to latest linux-next code
Changes in v2:
* Removed patch to implement slow_virt_to_phys() on ARM64.
Use of slow_virt_to_phys() in arch independent Hyper-V
drivers has been eliminated by commit 6ba34171bcbd
("Drivers: hv: vmbus: Remove use of slow_virt_to_phys()")
* Minor tweaks to rebase to latest linux-next code
Michael Kelley (4):
arm64: hyperv: Add core Hyper-V include files
arm64: hyperv: Add support for Hyper-V as a hypervisor
Drivers: hv: vmbus: Add hooks for per-CPU IRQ
Drivers: hv: Enable CONFIG_HYPERV on ARM64
MAINTAINERS | 4 +
arch/arm64/Makefile | 1 +
arch/arm64/hyperv/Makefile | 2 +
arch/arm64/hyperv/hv_hvc.S | 54 +
arch/arm64/hyperv/hv_init.c | 441 +++
arch/arm64/hyperv/mshyperv.c | 178 ++
arch/arm64/include/asm/hyperv-tlfs.h | 338 +++
arch/arm64/include/asm/mshyperv.h| 116 +
arch/x86/include/asm/mshyperv.h | 4 +
drivers/hv/Kconfig | 3 +-
drivers/hv/hv.c | 2 +
include/asm-generic/mshyperv.h | 240 +++
12 files changed, 1382 insertions(+), 1 deletion(-)
create mode 100644 arch/arm64/hyperv/Makefile
create mode 100644 arch/arm64/hyperv/hv_hvc.S
create mode 100644 arch/arm64/hyperv/hv_init.c
create mode 100644 arch/arm64/hyperv/mshyperv.c
create mode 100644 arch/arm64/include/asm/hyperv-tlfs.h
create mode 100644 arch/arm64/include/asm/mshyperv.h
create mode 100644 include/asm-generic/mshyperv.h
--
1.8.3.1
[no subject]
From: Stefan Popa To: ji...@kernel.org Cc: michael.henner...@analog.com, knaac...@gmx.de, l...@metafoo.de, pme...@pmeerw.net, gre...@linuxfoundation.org, linux-kernel@vger.kernel.org, linux-...@vger.kernel.org, stefan.p...@analog.com Subject: [PATCH v3 2/3] iio: adc: Add ad7124 support Date: Mon, 29 Oct 2018 18:37:26 +0200 Message-Id: <1540831046-2867-1-git-send-email-stefan.p...@analog.com> X-Mailer: git-send-email 2.7.4 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The ad7124-4 and ad7124-8 are a family of 4 and 8 channel sigma-delta ADCs with 24-bit precision and reference. Three power modes are available which in turn affect the output data rate: * Full power: 9.38 SPS to 19,200 SPS * Mid power: 2.34 SPS to 4800 SPS * Low power: 1.17 SPS to 2400 SPS The ad7124-4 can be configured to have four differential inputs, while ad7124-8 can have 8. Moreover, ad7124 also supports per channel configuration. Each configuration consists of gain, reference source, output data rate and bipolar/unipolar configuration. Datasheets: Link: http://www.analog.com/media/en/technical-documentation/data-sheets/AD7124-4.pdf Link: http://www.analog.com/media/en/technical-documentation/data-sheets/ad7124-8.pdf Signed-off-by: Stefan Popa --- Changes in v2: - Added this commit. Changes in v3: - Removed channel, address, scan_index and shift fields from ad7124_channel_template. - Added a sanity check for val2 in ad7124_write_raw(). - Used the "reg" property to get the channel address and "adi,diff-channels" for the differential pins. The "adi,channel-number" property was removed. - When calling regulator_get_optional, the probe is given up in case of error, but continues in case of -ENODEV. - clk_disable_unprepare() is called before ad_sd_cleanup_buffer_and_trigger in ad7124_remove(). MAINTAINERS | 7 + drivers/iio/adc/Kconfig | 11 + drivers/iio/adc/Makefile | 1 + drivers/iio/adc/ad7124.c | 648 +++ 4 files changed, 667 insertions(+) create mode 100644 drivers/iio/adc/ad7124.c diff --git a/MAINTAINERS b/MAINTAINERS index f642044..3a1bfcb 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -839,6 +839,13 @@ S: Supported F: drivers/iio/dac/ad5758.c F: Documentation/devicetree/bindings/iio/dac/ad5758.txt +ANALOG DEVICES INC AD7124 DRIVER +M: Stefan Popa +L: linux-...@vger.kernel.org +W: http://ez.analog.com/community/linux-device-drivers +S: Supported +F: drivers/iio/adc/ad7124.c + ANALOG DEVICES INC AD9389B DRIVER M: Hans Verkuil L: linux-me...@vger.kernel.org diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig index a52fea8..148a10f 100644 --- a/drivers/iio/adc/Kconfig +++ b/drivers/iio/adc/Kconfig @@ -10,6 +10,17 @@ config AD_SIGMA_DELTA select IIO_BUFFER select IIO_TRIGGERED_BUFFER +config AD7124 + tristate "Analog Devices AD7124 and similar sigma-delta ADCs driver" + depends on SPI_MASTER + select AD_SIGMA_DELTA + help + Say yes here to build support for Analog Devices AD7124-4 and AD7124-8 + SPI analog to digital converters (ADC). + + To compile this driver as a module, choose M here: the module will be + called ad7124. + config AD7266 tristate "Analog Devices AD7265/AD7266 ADC driver" depends on SPI_MASTER diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile index a6e6a0b..76168b2 100644 --- a/drivers/iio/adc/Makefile +++ b/drivers/iio/adc/Makefile @@ -5,6 +5,7 @@ # When adding new entries keep the list in alphabetical order obj-$(CONFIG_AD_SIGMA_DELTA) += ad_sigma_delta.o +obj-$(CONFIG_AD7124) += ad7124.o obj-$(CONFIG_AD7266) += ad7266.o obj-$(CONFIG_AD7291) += ad7291.o obj-$(CONFIG_AD7298) += ad7298.o diff --git a/drivers/iio/adc/ad7124.c b/drivers/iio/adc/ad7124.c new file mode 100644 index 000..0660135 --- /dev/null +++ b/drivers/iio/adc/ad7124.c @@ -0,0 +1,648 @@ +// SPDX-License-Identifier: GPL-2.0+ +/* + * AD7124 SPI ADC driver + * + * Copyright 2018 Analog Devices Inc. + */ +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include +#include + +/* AD7124 registers */ +#define AD7124_COMMS 0x00 +#define AD7124_STATUS 0x00 +#define AD7124_ADC_CONTROL 0x01 +#define AD7124_DATA0x02 +#define AD7124_IO_CONTROL_10x03 +#define AD7124_IO_CONTROL_20x04 +#define AD7124_ID 0x05 +#define AD7124_ERROR 0x06 +#define AD7124_ERROR_EN0x07 +#define AD7124_MCLK_COUNT 0x08 +#define AD7124_CHANNEL(x) (0x09 + (x)) +#def
[no subject]
From: Stefan Popa To: ji...@kernel.org Cc: michael.henner...@analog.com, knaac...@gmx.de, l...@metafoo.de, pme...@pmeerw.net, gre...@linuxfoundation.org, linux-kernel@vger.kernel.org, linux-...@vger.kernel.org, stefan.p...@analog.com Subject: [PATCH v3 2/3] iio: adc: Add ad7124 support Date: Mon, 29 Oct 2018 18:37:26 +0200 Message-Id: <1540831046-2867-1-git-send-email-stefan.p...@analog.com> X-Mailer: git-send-email 2.7.4 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The ad7124-4 and ad7124-8 are a family of 4 and 8 channel sigma-delta ADCs with 24-bit precision and reference. Three power modes are available which in turn affect the output data rate: * Full power: 9.38 SPS to 19,200 SPS * Mid power: 2.34 SPS to 4800 SPS * Low power: 1.17 SPS to 2400 SPS The ad7124-4 can be configured to have four differential inputs, while ad7124-8 can have 8. Moreover, ad7124 also supports per channel configuration. Each configuration consists of gain, reference source, output data rate and bipolar/unipolar configuration. Datasheets: Link: http://www.analog.com/media/en/technical-documentation/data-sheets/AD7124-4.pdf Link: http://www.analog.com/media/en/technical-documentation/data-sheets/ad7124-8.pdf Signed-off-by: Stefan Popa --- Changes in v2: - Added this commit. Changes in v3: - Removed channel, address, scan_index and shift fields from ad7124_channel_template. - Added a sanity check for val2 in ad7124_write_raw(). - Used the "reg" property to get the channel address and "adi,diff-channels" for the differential pins. The "adi,channel-number" property was removed. - When calling regulator_get_optional, the probe is given up in case of error, but continues in case of -ENODEV. - clk_disable_unprepare() is called before ad_sd_cleanup_buffer_and_trigger in ad7124_remove(). MAINTAINERS | 7 + drivers/iio/adc/Kconfig | 11 + drivers/iio/adc/Makefile | 1 + drivers/iio/adc/ad7124.c | 648 +++ 4 files changed, 667 insertions(+) create mode 100644 drivers/iio/adc/ad7124.c diff --git a/MAINTAINERS b/MAINTAINERS index f642044..3a1bfcb 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -839,6 +839,13 @@ S: Supported F: drivers/iio/dac/ad5758.c F: Documentation/devicetree/bindings/iio/dac/ad5758.txt +ANALOG DEVICES INC AD7124 DRIVER +M: Stefan Popa +L: linux-...@vger.kernel.org +W: http://ez.analog.com/community/linux-device-drivers +S: Supported +F: drivers/iio/adc/ad7124.c + ANALOG DEVICES INC AD9389B DRIVER M: Hans Verkuil L: linux-me...@vger.kernel.org diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig index a52fea8..148a10f 100644 --- a/drivers/iio/adc/Kconfig +++ b/drivers/iio/adc/Kconfig @@ -10,6 +10,17 @@ config AD_SIGMA_DELTA select IIO_BUFFER select IIO_TRIGGERED_BUFFER +config AD7124 + tristate "Analog Devices AD7124 and similar sigma-delta ADCs driver" + depends on SPI_MASTER + select AD_SIGMA_DELTA + help + Say yes here to build support for Analog Devices AD7124-4 and AD7124-8 + SPI analog to digital converters (ADC). + + To compile this driver as a module, choose M here: the module will be + called ad7124. + config AD7266 tristate "Analog Devices AD7265/AD7266 ADC driver" depends on SPI_MASTER diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile index a6e6a0b..76168b2 100644 --- a/drivers/iio/adc/Makefile +++ b/drivers/iio/adc/Makefile @@ -5,6 +5,7 @@ # When adding new entries keep the list in alphabetical order obj-$(CONFIG_AD_SIGMA_DELTA) += ad_sigma_delta.o +obj-$(CONFIG_AD7124) += ad7124.o obj-$(CONFIG_AD7266) += ad7266.o obj-$(CONFIG_AD7291) += ad7291.o obj-$(CONFIG_AD7298) += ad7298.o diff --git a/drivers/iio/adc/ad7124.c b/drivers/iio/adc/ad7124.c new file mode 100644 index 000..0660135 --- /dev/null +++ b/drivers/iio/adc/ad7124.c @@ -0,0 +1,648 @@ +// SPDX-License-Identifier: GPL-2.0+ +/* + * AD7124 SPI ADC driver + * + * Copyright 2018 Analog Devices Inc. + */ +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include +#include + +/* AD7124 registers */ +#define AD7124_COMMS 0x00 +#define AD7124_STATUS 0x00 +#define AD7124_ADC_CONTROL 0x01 +#define AD7124_DATA0x02 +#define AD7124_IO_CONTROL_10x03 +#define AD7124_IO_CONTROL_20x04 +#define AD7124_ID 0x05 +#define AD7124_ERROR 0x06 +#define AD7124_ERROR_EN0x07 +#define AD7124_MCLK_COUNT 0x08 +#define AD7124_CHANNEL(x) (0x09 + (x)) +#def
[no subject]
FROM: DR. JONATHAN JUJU ACH REPUBLIC OF SOUTH AFRICA. Attn: Sir/Ma YOUR COMPANY'S OPERATIONS AND PROFILE GOT MY ATTENTION, IN LINE WITH MY CURRENT DIVERSIFICATION AND EXPANSION PROGRAM IN CREATING STRATEGIC PARTNERSHIP I WOULD LIKE TO KNOW IF THERE ARE AVAILABLE PARTNERSHIP OPTIONS AND OPENINGS FOR NEW INVESTORS WITHIN YOUR FIRM. I THEREFORE,SOLICIT PARTNERSHIP WITH YOU BY PROVIDING THE FUNDS FOR INVESTMENT IN ANY PROJECT IN YOUR COUNTRY. THE INVESTMENT FUNDS ARE AVAILABLE FOR TRANSFER FURTHER INFORMATION AND INSTRUCTIONS WOULD BE COMMUNICATED TO YOU ON YOUR RESPONSE AND DECLARATION OF INTEREST. YOUR HONEST COOPERATION WOULD BE HIGHLY APPRECIATED TO ENABLE ME SUCCESSFULLY EXECUTE THE TRANSFER OF THESE FUNDS OUT OF THE SHORES OF AFRICA AND INVEST IN ANY LAUDABLE PROJECT THAT WILL EARN GOOD RETURNS. PLEASE, CALL OR SEND A FAX TO TEL:. +27- 60-3015081 / FAX:.+ 27- 86-610-8465 FOR FURTHER DISCUSSIONS AND ACQUAINTANCE. I LOOK FORWARD TO YOUR URGENT AND POSITIVE RESPONSE. YOURS SINCERELY, DR.JONATHAN JUJU NOTE: This is a CONFIDENTIAL message. Please, treat as such. Kindly destroy it if you are not interested,.
[no subject]
FROM: DR. JONATHAN JUJU ACH REPUBLIC OF SOUTH AFRICA. Attn: Sir/Ma YOUR COMPANY'S OPERATIONS AND PROFILE GOT MY ATTENTION, IN LINE WITH MY CURRENT DIVERSIFICATION AND EXPANSION PROGRAM IN CREATING STRATEGIC PARTNERSHIP I WOULD LIKE TO KNOW IF THERE ARE AVAILABLE PARTNERSHIP OPTIONS AND OPENINGS FOR NEW INVESTORS WITHIN YOUR FIRM. I THEREFORE,SOLICIT PARTNERSHIP WITH YOU BY PROVIDING THE FUNDS FOR INVESTMENT IN ANY PROJECT IN YOUR COUNTRY. THE INVESTMENT FUNDS ARE AVAILABLE FOR TRANSFER FURTHER INFORMATION AND INSTRUCTIONS WOULD BE COMMUNICATED TO YOU ON YOUR RESPONSE AND DECLARATION OF INTEREST. YOUR HONEST COOPERATION WOULD BE HIGHLY APPRECIATED TO ENABLE ME SUCCESSFULLY EXECUTE THE TRANSFER OF THESE FUNDS OUT OF THE SHORES OF AFRICA AND INVEST IN ANY LAUDABLE PROJECT THAT WILL EARN GOOD RETURNS. PLEASE, CALL OR SEND A FAX TO TEL:. +27- 60-3015081 / FAX:.+ 27- 86-610-8465 FOR FURTHER DISCUSSIONS AND ACQUAINTANCE. I LOOK FORWARD TO YOUR URGENT AND POSITIVE RESPONSE. YOURS SINCERELY, DR.JONATHAN JUJU NOTE: This is a CONFIDENTIAL message. Please, treat as such. Kindly destroy it if you are not interested,.
[no subject]
I wrote you about late Engr M.M. and the deposit he made at the bank here.I sent you an email earlier and been expecting to hear from you. Please try and get back to me. Steven
[no subject]
I wrote you about late Engr M.M. and the deposit he made at the bank here.I sent you an email earlier and been expecting to hear from you. Please try and get back to me. Steven
[no subject]
From: Stefan Popa To: ji...@kernel.org Cc: michael.henner...@analog.com, knaac...@gmx.de, l...@metafoo.de, pme...@pmeerw.net, gre...@linuxfoundation.org, linux-kernel@vger.kernel.org, linux-...@vger.kernel.org, de...@driverdev.osuosl.org, stefan.p...@analog.com Subject: [PATCH 1/2] staging: iio: ad7606: Move out of staging Date: Thu, 18 Oct 2018 12:08:32 +0300 Message-Id: <1539853712-26253-1-git-send-email-stefan.p...@analog.com> X-Mailer: git-send-email 2.7.4 Move ad7606 ADC driver out of staging and into the mainline. Signed-off-by: Stefan Popa --- MAINTAINERS | 7 + drivers/iio/adc/Kconfig | 34 +++ drivers/iio/adc/Makefile | 3 + drivers/iio/adc/ad7606.c | 565 +++ drivers/iio/adc/ad7606.h | 106 +++ drivers/iio/adc/ad7606_par.c | 113 +++ drivers/iio/adc/ad7606_spi.c | 79 + drivers/staging/iio/adc/Kconfig | 34 --- drivers/staging/iio/adc/Makefile | 3 - drivers/staging/iio/adc/ad7606.c | 565 --- drivers/staging/iio/adc/ad7606.h | 106 --- drivers/staging/iio/adc/ad7606_par.c | 113 --- drivers/staging/iio/adc/ad7606_spi.c | 79 - 13 files changed, 907 insertions(+), 900 deletions(-) create mode 100644 drivers/iio/adc/ad7606.c create mode 100644 drivers/iio/adc/ad7606.h create mode 100644 drivers/iio/adc/ad7606_par.c create mode 100644 drivers/iio/adc/ad7606_spi.c delete mode 100644 drivers/staging/iio/adc/ad7606.c delete mode 100644 drivers/staging/iio/adc/ad7606.h delete mode 100644 drivers/staging/iio/adc/ad7606_par.c delete mode 100644 drivers/staging/iio/adc/ad7606_spi.c diff --git a/MAINTAINERS b/MAINTAINERS index f642044..843545d 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -839,6 +839,13 @@ S: Supported F: drivers/iio/dac/ad5758.c F: Documentation/devicetree/bindings/iio/dac/ad5758.txt +ANALOG DEVICES INC AD7606 DRIVER +M: Stefan Popa +L: linux-...@vger.kernel.org +W: http://ez.analog.com/community/linux-device-drivers +S: Supported +F: drivers/iio/adc/ad7606.c + ANALOG DEVICES INC AD9389B DRIVER M: Hans Verkuil L: linux-me...@vger.kernel.org diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig index a52fea8..22bafdc 100644 --- a/drivers/iio/adc/Kconfig +++ b/drivers/iio/adc/Kconfig @@ -58,6 +58,40 @@ config AD7476 To compile this driver as a module, choose M here: the module will be called ad7476. +config AD7606 + tristate "Analog Devices AD7606 ADC driver" + depends on GPIOLIB || COMPILE_TEST + depends on HAS_IOMEM + select IIO_BUFFER + select IIO_TRIGGERED_BUFFER + help + Say yes here to build support for Analog Devices: + ad7605-4, ad7606, ad7606-6, ad7606-4 analog to digital converters (ADC). + + To compile this driver as a module, choose M here: the + module will be called ad7606. + +config AD7606_IFACE_PARALLEL + tristate "parallel interface support" + depends on AD7606 + help + Say yes here to include parallel interface support on the AD7606 + ADC driver. + + To compile this driver as a module, choose M here: the + module will be called ad7606_parallel. + +config AD7606_IFACE_SPI + tristate "spi interface support" + depends on AD7606 + depends on SPI + help + Say yes here to include parallel interface support on the AD7606 + ADC driver. + + To compile this driver as a module, choose M here: the + module will be called ad7606_spi. + config AD7766 tristate "Analog Devices AD7766/AD7767 ADC driver" depends on SPI_MASTER diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile index a6e6a0b..b734f4f 100644 --- a/drivers/iio/adc/Makefile +++ b/drivers/iio/adc/Makefile @@ -8,6 +8,9 @@ obj-$(CONFIG_AD_SIGMA_DELTA) += ad_sigma_delta.o obj-$(CONFIG_AD7266) += ad7266.o obj-$(CONFIG_AD7291) += ad7291.o obj-$(CONFIG_AD7298) += ad7298.o +obj-$(CONFIG_AD7606_IFACE_PARALLEL) += ad7606_par.o +obj-$(CONFIG_AD7606_IFACE_SPI) += ad7606_spi.o +obj-$(CONFIG_AD7606) += ad7606.o obj-$(CONFIG_AD7923) += ad7923.o obj-$(CONFIG_AD7476) += ad7476.o obj-$(CONFIG_AD7766) += ad7766.o diff --git a/drivers/iio/adc/ad7606.c b/drivers/iio/adc/ad7606.c new file mode 100644 index 000..0b728b6 --- /dev/null +++ b/drivers/iio/adc/ad7606.c @@ -0,0 +1,565 @@ +/* + * AD7606 SPI ADC driver + * + * Copyright 2011 Analog Devices Inc. + * + * Licensed under the GPL-2. + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include +#include +#include +#include + +#include "ad7606.h" + +/* + * Scales are computed as 5
[no subject]
From: Stefan Popa To: ji...@kernel.org Cc: michael.henner...@analog.com, knaac...@gmx.de, l...@metafoo.de, pme...@pmeerw.net, gre...@linuxfoundation.org, linux-kernel@vger.kernel.org, linux-...@vger.kernel.org, de...@driverdev.osuosl.org, stefan.p...@analog.com Subject: [PATCH 1/2] staging: iio: ad7606: Move out of staging Date: Thu, 18 Oct 2018 12:08:32 +0300 Message-Id: <1539853712-26253-1-git-send-email-stefan.p...@analog.com> X-Mailer: git-send-email 2.7.4 Move ad7606 ADC driver out of staging and into the mainline. Signed-off-by: Stefan Popa --- MAINTAINERS | 7 + drivers/iio/adc/Kconfig | 34 +++ drivers/iio/adc/Makefile | 3 + drivers/iio/adc/ad7606.c | 565 +++ drivers/iio/adc/ad7606.h | 106 +++ drivers/iio/adc/ad7606_par.c | 113 +++ drivers/iio/adc/ad7606_spi.c | 79 + drivers/staging/iio/adc/Kconfig | 34 --- drivers/staging/iio/adc/Makefile | 3 - drivers/staging/iio/adc/ad7606.c | 565 --- drivers/staging/iio/adc/ad7606.h | 106 --- drivers/staging/iio/adc/ad7606_par.c | 113 --- drivers/staging/iio/adc/ad7606_spi.c | 79 - 13 files changed, 907 insertions(+), 900 deletions(-) create mode 100644 drivers/iio/adc/ad7606.c create mode 100644 drivers/iio/adc/ad7606.h create mode 100644 drivers/iio/adc/ad7606_par.c create mode 100644 drivers/iio/adc/ad7606_spi.c delete mode 100644 drivers/staging/iio/adc/ad7606.c delete mode 100644 drivers/staging/iio/adc/ad7606.h delete mode 100644 drivers/staging/iio/adc/ad7606_par.c delete mode 100644 drivers/staging/iio/adc/ad7606_spi.c diff --git a/MAINTAINERS b/MAINTAINERS index f642044..843545d 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -839,6 +839,13 @@ S: Supported F: drivers/iio/dac/ad5758.c F: Documentation/devicetree/bindings/iio/dac/ad5758.txt +ANALOG DEVICES INC AD7606 DRIVER +M: Stefan Popa +L: linux-...@vger.kernel.org +W: http://ez.analog.com/community/linux-device-drivers +S: Supported +F: drivers/iio/adc/ad7606.c + ANALOG DEVICES INC AD9389B DRIVER M: Hans Verkuil L: linux-me...@vger.kernel.org diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig index a52fea8..22bafdc 100644 --- a/drivers/iio/adc/Kconfig +++ b/drivers/iio/adc/Kconfig @@ -58,6 +58,40 @@ config AD7476 To compile this driver as a module, choose M here: the module will be called ad7476. +config AD7606 + tristate "Analog Devices AD7606 ADC driver" + depends on GPIOLIB || COMPILE_TEST + depends on HAS_IOMEM + select IIO_BUFFER + select IIO_TRIGGERED_BUFFER + help + Say yes here to build support for Analog Devices: + ad7605-4, ad7606, ad7606-6, ad7606-4 analog to digital converters (ADC). + + To compile this driver as a module, choose M here: the + module will be called ad7606. + +config AD7606_IFACE_PARALLEL + tristate "parallel interface support" + depends on AD7606 + help + Say yes here to include parallel interface support on the AD7606 + ADC driver. + + To compile this driver as a module, choose M here: the + module will be called ad7606_parallel. + +config AD7606_IFACE_SPI + tristate "spi interface support" + depends on AD7606 + depends on SPI + help + Say yes here to include parallel interface support on the AD7606 + ADC driver. + + To compile this driver as a module, choose M here: the + module will be called ad7606_spi. + config AD7766 tristate "Analog Devices AD7766/AD7767 ADC driver" depends on SPI_MASTER diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile index a6e6a0b..b734f4f 100644 --- a/drivers/iio/adc/Makefile +++ b/drivers/iio/adc/Makefile @@ -8,6 +8,9 @@ obj-$(CONFIG_AD_SIGMA_DELTA) += ad_sigma_delta.o obj-$(CONFIG_AD7266) += ad7266.o obj-$(CONFIG_AD7291) += ad7291.o obj-$(CONFIG_AD7298) += ad7298.o +obj-$(CONFIG_AD7606_IFACE_PARALLEL) += ad7606_par.o +obj-$(CONFIG_AD7606_IFACE_SPI) += ad7606_spi.o +obj-$(CONFIG_AD7606) += ad7606.o obj-$(CONFIG_AD7923) += ad7923.o obj-$(CONFIG_AD7476) += ad7476.o obj-$(CONFIG_AD7766) += ad7766.o diff --git a/drivers/iio/adc/ad7606.c b/drivers/iio/adc/ad7606.c new file mode 100644 index 000..0b728b6 --- /dev/null +++ b/drivers/iio/adc/ad7606.c @@ -0,0 +1,565 @@ +/* + * AD7606 SPI ADC driver + * + * Copyright 2011 Analog Devices Inc. + * + * Licensed under the GPL-2. + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include +#include +#include +#include + +#include "ad7606.h" + +/* + * Scales are computed as 5
[no subject]
[no subject]
[no subject]
[no subject]
[no subject]
DO YOU NEED A LOAN OF ANY KIND, IF YES GET BACK WITH THE BELOW INFORMATION. Your full name Amount needed Duration Country Purpose of funds Phone number
[no subject]
DO YOU NEED A LOAN OF ANY KIND, IF YES GET BACK WITH THE BELOW INFORMATION. Your full name Amount needed Duration Country Purpose of funds Phone number
[no subject]
สวัสดีวันดีขอให้คุณเขียนจดหมายกลับมาฉันมีเรื่องสำคัญในการพูดคุยกับคุณ
[no subject]
สวัสดีวันดีขอให้คุณเขียนจดหมายกลับมาฉันมีเรื่องสำคัญในการพูดคุยกับคุณ
[no subject]
Hola querida, ¿Cómo está? Mucho gusto? Por favor, responda de nuevo. Tengo algo importante que discutir con usted. Gracias, soy jessica umeir.
[no subject]
Hola querida, ¿Cómo está? Mucho gusto? Por favor, responda de nuevo. Tengo algo importante que discutir con usted. Gracias, soy jessica umeir.
[no subject]
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: hornbeckmajorden...@gmail.com Regards, Major Dennis Hornbeck.
[no subject]
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: hornbeckmajorden...@gmail.com Regards, Major Dennis Hornbeck.
[no subject]
Confidential! Open the attached for details letter.rtf Description: RTF file
[no subject]
Confidential! Open the attached for details letter.rtf Description: RTF file
[no subject]
I am Mr.Sheng Li Hung, from china I got your information while search for a reliable person, I have a very profitable business proposition for you and i can assure you that you will not regret been part of this mutual beneficial transaction after completion. Kindly get back to me for more details on this email id: shengl...@outlook.com Thanks Mr Sheng Li Hung
[no subject]
I am Mr.Sheng Li Hung, from china I got your information while search for a reliable person, I have a very profitable business proposition for you and i can assure you that you will not regret been part of this mutual beneficial transaction after completion. Kindly get back to me for more details on this email id: shengl...@outlook.com Thanks Mr Sheng Li Hung
[no subject]
My Dear This letter is to acknowledge the substantial contributions of time and energy you have made in trying to assist to claim the fund through your account, despite that it failed us because of your inability to continue financing the transaction. Besides I'm happy to inform you that I have succeeded in transferring the fund out of my home Country with the help of a new partner from Tuvalu. I am now in Tuvalu for investment and Tuvalu is composed of 9 coral atolls along a 360 mile chain in Polynesia. They gained independence in 1978 the former Ellice Islands. Therefore in appreciation of your earlier assistance, I have decided to compensate you with the sum of $850.000.00 USD which I raised in ATM CARD on your favour. This fund I have given to you has been deposited with a bank which has already opened an account and issued to you ATM CARD worth US$850.000.00 (Eight Hundred and Fifty Thousand United States Dollars) The ATM CARD is withdrawable from any ATM Machine in the world. So feel free and contact my Secretary in Benin Republic, her name is Mrs.Linda Brown Address: Carre 1299, Ste Rita City Cotonou,Benin Republic Email: (mrs.linda_bro...@yahoo.com) and instruct her to send the ATM CARD to you. Please do let me know immediately you receive it. Regards, Mr.Nolan Jan
[no subject]
My Dear This letter is to acknowledge the substantial contributions of time and energy you have made in trying to assist to claim the fund through your account, despite that it failed us because of your inability to continue financing the transaction. Besides I'm happy to inform you that I have succeeded in transferring the fund out of my home Country with the help of a new partner from Tuvalu. I am now in Tuvalu for investment and Tuvalu is composed of 9 coral atolls along a 360 mile chain in Polynesia. They gained independence in 1978 the former Ellice Islands. Therefore in appreciation of your earlier assistance, I have decided to compensate you with the sum of $850.000.00 USD which I raised in ATM CARD on your favour. This fund I have given to you has been deposited with a bank which has already opened an account and issued to you ATM CARD worth US$850.000.00 (Eight Hundred and Fifty Thousand United States Dollars) The ATM CARD is withdrawable from any ATM Machine in the world. So feel free and contact my Secretary in Benin Republic, her name is Mrs.Linda Brown Address: Carre 1299, Ste Rita City Cotonou,Benin Republic Email: (mrs.linda_bro...@yahoo.com) and instruct her to send the ATM CARD to you. Please do let me know immediately you receive it. Regards, Mr.Nolan Jan
[no subject]
unsubscribe linux-kernel -- Best regards Kassey
[no subject]
unsubscribe linux-kernel -- Best regards Kassey
[no subject]
-- join the Illuminati secret brotherhood and get $3,000,000.00
[no subject]
-- join the Illuminati secret brotherhood and get $3,000,000.00
[no subject]
-- join the Illuminati secret brotherhood and get $3,000,000.00
[no subject]
-- join the Illuminati secret brotherhood and get $3,000,000.00
[no subject]
hi https://goo.gl/djjKWM
[no subject]
hi https://goo.gl/djjKWM
[no subject]
Compliments of the season! Please excuse me if I interfere into your privacy in this manner,I am Barrister Kevin Gregory Esq. I have a deal that will interest you, by indicating your interest, I will send you the full details on how it will be executed. For more information please indicate by responding to my mail thank you. Very truly yours, Barrister Kevin Gregory Esq.
[no subject]
Compliments of the season! Please excuse me if I interfere into your privacy in this manner,I am Barrister Kevin Gregory Esq. I have a deal that will interest you, by indicating your interest, I will send you the full details on how it will be executed. For more information please indicate by responding to my mail thank you. Very truly yours, Barrister Kevin Gregory Esq.
[no subject]
Linus, please pull the latest x86-urgent-for-linus git tree from: git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86-urgent-for-linus x86 specific updates for 4.19: Speculation: - Make the micro code check more robust - Make the L1TF memory limit depend on the internal cache physical address space and not on the CPUID advertised physical address space, which might be significantly smaller. This avoids disabling L1TF on machines which utilize the full physical address space. - Fix the GDT mapping for EFI calls on 32bit PTI - Fix the MCE nospec implementation to prevent #GP Fixes and robustness: - Use the proper operand order for LSL in the VDSO - Prevent NMI uaccess race against CR3 switching - Add a lockdep check to verify that text_mutex is held in text_poke() functions - Repair the fallout of giving native_restore_fl() a prototype - Prevent kernel memory dumps based on usermode RIP - Wipe KASAN shadow stack before rewinding the stack to prevent false positives - Move the AMS GOTO enforcement to the actual build stage to allow user API header extraction without a compiler Miscelaneous: - Trivial typo, GCC quirk removal and CC_SET/OUT() cleanups. Thanks, tglx --> Andi Kleen (2): x86/spectre: Add missing family 6 check to microcode check x86/speculation/l1tf: Increase l1tf memory limit for Nehalem+ Andy Lutomirski (1): x86/nmi: Fix NMI uaccess race against CR3 switching Ben Hutchings (1): x86: Allow generating user-space headers without a compiler Jann Horn (2): x86/entry/64: Wipe KASAN stack shadow before rewind_stack_do_exit() x86/dumpstack: Don't dump kernel memory based on usermode RIP Jiri Kosina (1): x86/alternatives: Lockdep-enforce text_mutex in text_poke*() Joerg Roedel (1): x86/efi: Load fixmap GDT in efi_call_phys_epilog() Masahiro Yamada (1): x86/build: Remove jump label quirk for GCC older than 4.5.2 Nick Desaulniers (1): x86/irqflags: Mark native_restore_fl extern inline Nikolas Nyby (1): x86/Kconfig: Fix trivial typo Samuel Neves (1): x86/vdso: Fix lsl operand order Tony Luck (1): x86/mce: Fix set_mce_nospec() to avoid #GP fault Uros Bizjak (1): x86/asm: Use CC_SET()/CC_OUT() in __gen_sigismember() arch/x86/Kconfig | 2 +- arch/x86/Makefile | 23 ++-- arch/x86/events/core.c| 2 +- arch/x86/include/asm/irqflags.h | 3 ++- arch/x86/include/asm/processor.h | 4 +++- arch/x86/include/asm/signal.h | 7 +++--- arch/x86/include/asm/stacktrace.h | 2 +- arch/x86/include/asm/tlbflush.h | 40 ++ arch/x86/include/asm/vgtod.h | 2 +- arch/x86/kernel/alternative.c | 9 arch/x86/kernel/cpu/bugs.c| 46 ++- arch/x86/kernel/cpu/common.c | 1 + arch/x86/kernel/cpu/intel.c | 3 +++ arch/x86/kernel/dumpstack.c | 20 ++--- arch/x86/lib/usercopy.c | 5 + arch/x86/mm/fault.c | 2 +- arch/x86/mm/pageattr.c| 25 - arch/x86/mm/tlb.c | 7 ++ arch/x86/platform/efi/efi_32.c| 8 ++- scripts/Kbuild.include| 4 20 files changed, 166 insertions(+), 49 deletions(-) diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index c5ff296bc5d1..1a0be022f91d 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -2843,7 +2843,7 @@ config X86_SYSFB This option, if enabled, marks VGA/VBE/EFI framebuffers as generic framebuffers so the new generic system-framebuffer drivers can be used on x86. If the framebuffer is not compatible with the generic - modes, it is adverticed as fallback platform framebuffer so legacy + modes, it is advertised as fallback platform framebuffer so legacy drivers like efifb, vesafb and uvesafb can pick it up. If this option is not selected, all system framebuffers are always marked as fallback platform framebuffers as usual. diff --git a/arch/x86/Makefile b/arch/x86/Makefile index 94859241bc3e..8f6e7eb8ae9f 100644 --- a/arch/x86/Makefile +++ b/arch/x86/Makefile @@ -175,22 +175,6 @@ ifdef CONFIG_FUNCTION_GRAPH_TRACER endif endif -ifndef CC_HAVE_ASM_GOTO - $(error Compiler lacks asm-goto support.) -endif - -# -# Jump labels need '-maccumulate-outgoing-args' for gcc < 4.5.2 to prevent a -# GCC bug (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46226). There's no way -# to test for this bug at compile-time because the test case needs to execute, -# which is a no-go for cross compilers. So check the GCC version instead. -# -ifdef CONFIG_JUMP_LABEL - ifneq ($(ACCUMULATE_OUTGOING_ARGS), 1) - ACCUMULATE_OUTGOING_ARGS = $(call cc-if-fullversion, -lt, 040502, 1) - endif -endif - ifeq ($(ACCUMULATE_OUTGOING_ARGS), 1)
[no subject]
Linus, please pull the latest x86-urgent-for-linus git tree from: git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86-urgent-for-linus x86 specific updates for 4.19: Speculation: - Make the micro code check more robust - Make the L1TF memory limit depend on the internal cache physical address space and not on the CPUID advertised physical address space, which might be significantly smaller. This avoids disabling L1TF on machines which utilize the full physical address space. - Fix the GDT mapping for EFI calls on 32bit PTI - Fix the MCE nospec implementation to prevent #GP Fixes and robustness: - Use the proper operand order for LSL in the VDSO - Prevent NMI uaccess race against CR3 switching - Add a lockdep check to verify that text_mutex is held in text_poke() functions - Repair the fallout of giving native_restore_fl() a prototype - Prevent kernel memory dumps based on usermode RIP - Wipe KASAN shadow stack before rewinding the stack to prevent false positives - Move the AMS GOTO enforcement to the actual build stage to allow user API header extraction without a compiler Miscelaneous: - Trivial typo, GCC quirk removal and CC_SET/OUT() cleanups. Thanks, tglx --> Andi Kleen (2): x86/spectre: Add missing family 6 check to microcode check x86/speculation/l1tf: Increase l1tf memory limit for Nehalem+ Andy Lutomirski (1): x86/nmi: Fix NMI uaccess race against CR3 switching Ben Hutchings (1): x86: Allow generating user-space headers without a compiler Jann Horn (2): x86/entry/64: Wipe KASAN stack shadow before rewind_stack_do_exit() x86/dumpstack: Don't dump kernel memory based on usermode RIP Jiri Kosina (1): x86/alternatives: Lockdep-enforce text_mutex in text_poke*() Joerg Roedel (1): x86/efi: Load fixmap GDT in efi_call_phys_epilog() Masahiro Yamada (1): x86/build: Remove jump label quirk for GCC older than 4.5.2 Nick Desaulniers (1): x86/irqflags: Mark native_restore_fl extern inline Nikolas Nyby (1): x86/Kconfig: Fix trivial typo Samuel Neves (1): x86/vdso: Fix lsl operand order Tony Luck (1): x86/mce: Fix set_mce_nospec() to avoid #GP fault Uros Bizjak (1): x86/asm: Use CC_SET()/CC_OUT() in __gen_sigismember() arch/x86/Kconfig | 2 +- arch/x86/Makefile | 23 ++-- arch/x86/events/core.c| 2 +- arch/x86/include/asm/irqflags.h | 3 ++- arch/x86/include/asm/processor.h | 4 +++- arch/x86/include/asm/signal.h | 7 +++--- arch/x86/include/asm/stacktrace.h | 2 +- arch/x86/include/asm/tlbflush.h | 40 ++ arch/x86/include/asm/vgtod.h | 2 +- arch/x86/kernel/alternative.c | 9 arch/x86/kernel/cpu/bugs.c| 46 ++- arch/x86/kernel/cpu/common.c | 1 + arch/x86/kernel/cpu/intel.c | 3 +++ arch/x86/kernel/dumpstack.c | 20 ++--- arch/x86/lib/usercopy.c | 5 + arch/x86/mm/fault.c | 2 +- arch/x86/mm/pageattr.c| 25 - arch/x86/mm/tlb.c | 7 ++ arch/x86/platform/efi/efi_32.c| 8 ++- scripts/Kbuild.include| 4 20 files changed, 166 insertions(+), 49 deletions(-) diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index c5ff296bc5d1..1a0be022f91d 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -2843,7 +2843,7 @@ config X86_SYSFB This option, if enabled, marks VGA/VBE/EFI framebuffers as generic framebuffers so the new generic system-framebuffer drivers can be used on x86. If the framebuffer is not compatible with the generic - modes, it is adverticed as fallback platform framebuffer so legacy + modes, it is advertised as fallback platform framebuffer so legacy drivers like efifb, vesafb and uvesafb can pick it up. If this option is not selected, all system framebuffers are always marked as fallback platform framebuffers as usual. diff --git a/arch/x86/Makefile b/arch/x86/Makefile index 94859241bc3e..8f6e7eb8ae9f 100644 --- a/arch/x86/Makefile +++ b/arch/x86/Makefile @@ -175,22 +175,6 @@ ifdef CONFIG_FUNCTION_GRAPH_TRACER endif endif -ifndef CC_HAVE_ASM_GOTO - $(error Compiler lacks asm-goto support.) -endif - -# -# Jump labels need '-maccumulate-outgoing-args' for gcc < 4.5.2 to prevent a -# GCC bug (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46226). There's no way -# to test for this bug at compile-time because the test case needs to execute, -# which is a no-go for cross compilers. So check the GCC version instead. -# -ifdef CONFIG_JUMP_LABEL - ifneq ($(ACCUMULATE_OUTGOING_ARGS), 1) - ACCUMULATE_OUTGOING_ARGS = $(call cc-if-fullversion, -lt, 040502, 1) - endif -endif - ifeq ($(ACCUMULATE_OUTGOING_ARGS), 1)
[no subject]
Linus,
please pull the latest smp-urgent-for-linus git tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
smp-urgent-for-linus
Remove the stale skip_onerr member from the hotplug states.
Thanks,
tglx
-->
Mukesh Ojha (1):
cpu/hotplug: Remove skip_onerr field from cpuhp_step structure
kernel/cpu.c | 26 --
1 file changed, 4 insertions(+), 22 deletions(-)
diff --git a/kernel/cpu.c b/kernel/cpu.c
index ed44d7d34c2d..aa7fe85ad62e 100644
--- a/kernel/cpu.c
+++ b/kernel/cpu.c
@@ -102,8 +102,6 @@ static inline void cpuhp_lock_release(bool bringup) { }
* @name: Name of the step
* @startup: Startup function of the step
* @teardown: Teardown function of the step
- * @skip_onerr:Do not invoke the functions on error rollback
- * Will go away once the notifiers are gone
* @cant_stop: Bringup/teardown can't be stopped at this step
*/
struct cpuhp_step {
@@ -119,7 +117,6 @@ struct cpuhp_step {
struct hlist_node *node);
} teardown;
struct hlist_head list;
- boolskip_onerr;
boolcant_stop;
boolmulti_instance;
};
@@ -550,12 +547,8 @@ static int bringup_cpu(unsigned int cpu)
static void undo_cpu_up(unsigned int cpu, struct cpuhp_cpu_state *st)
{
- for (st->state--; st->state > st->target; st->state--) {
- struct cpuhp_step *step = cpuhp_get_step(st->state);
-
- if (!step->skip_onerr)
- cpuhp_invoke_callback(cpu, st->state, false, NULL,
NULL);
- }
+ for (st->state--; st->state > st->target; st->state--)
+ cpuhp_invoke_callback(cpu, st->state, false, NULL, NULL);
}
static int cpuhp_up_callbacks(unsigned int cpu, struct cpuhp_cpu_state *st,
@@ -644,12 +637,6 @@ static void cpuhp_thread_fun(unsigned int cpu)
WARN_ON_ONCE(!cpuhp_is_ap_state(state));
- if (st->rollback) {
- struct cpuhp_step *step = cpuhp_get_step(state);
- if (step->skip_onerr)
- goto next;
- }
-
if (cpuhp_is_atomic_state(state)) {
local_irq_disable();
st->result = cpuhp_invoke_callback(cpu, state, bringup,
st->node, >last);
@@ -673,7 +660,6 @@ static void cpuhp_thread_fun(unsigned int cpu)
st->should_run = false;
}
-next:
cpuhp_lock_release(bringup);
if (!st->should_run)
@@ -916,12 +902,8 @@ void cpuhp_report_idle_dead(void)
static void undo_cpu_down(unsigned int cpu, struct cpuhp_cpu_state *st)
{
- for (st->state++; st->state < st->target; st->state++) {
- struct cpuhp_step *step = cpuhp_get_step(st->state);
-
- if (!step->skip_onerr)
- cpuhp_invoke_callback(cpu, st->state, true, NULL, NULL);
- }
+ for (st->state++; st->state < st->target; st->state++)
+ cpuhp_invoke_callback(cpu, st->state, true, NULL, NULL);
}
static int cpuhp_down_callbacks(unsigned int cpu, struct cpuhp_cpu_state *st,
[no subject]
Linus,
please pull the latest smp-urgent-for-linus git tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
smp-urgent-for-linus
Remove the stale skip_onerr member from the hotplug states.
Thanks,
tglx
-->
Mukesh Ojha (1):
cpu/hotplug: Remove skip_onerr field from cpuhp_step structure
kernel/cpu.c | 26 --
1 file changed, 4 insertions(+), 22 deletions(-)
diff --git a/kernel/cpu.c b/kernel/cpu.c
index ed44d7d34c2d..aa7fe85ad62e 100644
--- a/kernel/cpu.c
+++ b/kernel/cpu.c
@@ -102,8 +102,6 @@ static inline void cpuhp_lock_release(bool bringup) { }
* @name: Name of the step
* @startup: Startup function of the step
* @teardown: Teardown function of the step
- * @skip_onerr:Do not invoke the functions on error rollback
- * Will go away once the notifiers are gone
* @cant_stop: Bringup/teardown can't be stopped at this step
*/
struct cpuhp_step {
@@ -119,7 +117,6 @@ struct cpuhp_step {
struct hlist_node *node);
} teardown;
struct hlist_head list;
- boolskip_onerr;
boolcant_stop;
boolmulti_instance;
};
@@ -550,12 +547,8 @@ static int bringup_cpu(unsigned int cpu)
static void undo_cpu_up(unsigned int cpu, struct cpuhp_cpu_state *st)
{
- for (st->state--; st->state > st->target; st->state--) {
- struct cpuhp_step *step = cpuhp_get_step(st->state);
-
- if (!step->skip_onerr)
- cpuhp_invoke_callback(cpu, st->state, false, NULL,
NULL);
- }
+ for (st->state--; st->state > st->target; st->state--)
+ cpuhp_invoke_callback(cpu, st->state, false, NULL, NULL);
}
static int cpuhp_up_callbacks(unsigned int cpu, struct cpuhp_cpu_state *st,
@@ -644,12 +637,6 @@ static void cpuhp_thread_fun(unsigned int cpu)
WARN_ON_ONCE(!cpuhp_is_ap_state(state));
- if (st->rollback) {
- struct cpuhp_step *step = cpuhp_get_step(state);
- if (step->skip_onerr)
- goto next;
- }
-
if (cpuhp_is_atomic_state(state)) {
local_irq_disable();
st->result = cpuhp_invoke_callback(cpu, state, bringup,
st->node, >last);
@@ -673,7 +660,6 @@ static void cpuhp_thread_fun(unsigned int cpu)
st->should_run = false;
}
-next:
cpuhp_lock_release(bringup);
if (!st->should_run)
@@ -916,12 +902,8 @@ void cpuhp_report_idle_dead(void)
static void undo_cpu_down(unsigned int cpu, struct cpuhp_cpu_state *st)
{
- for (st->state++; st->state < st->target; st->state++) {
- struct cpuhp_step *step = cpuhp_get_step(st->state);
-
- if (!step->skip_onerr)
- cpuhp_invoke_callback(cpu, st->state, true, NULL, NULL);
- }
+ for (st->state++; st->state < st->target; st->state++)
+ cpuhp_invoke_callback(cpu, st->state, true, NULL, NULL);
}
static int cpuhp_down_callbacks(unsigned int cpu, struct cpuhp_cpu_state *st,
[no subject]
Linus,
please pull the latest core-urgent-for-linus git tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
core-urgent-for-linus
A small set of updates for core code:
- Prevent tracing in functions which are called from trace patching via
stop_machine() to prevent executing half patched function trace entries.
- Remove old GCC workarounds
- Remove pointless includes of notifier.h
Thanks,
tglx
-->
Masahiro Yamada (1):
objtool: Remove workaround for unreachable warnings from old GCC
Mukesh Ojha (1):
notifier: Remove notifier header file wherever not used
Vincent Whitchurch (1):
watchdog: Mark watchdog touch functions as notrace
fs/buffer.c| 1 -
kernel/printk/printk.c | 1 -
kernel/watchdog.c | 4 ++--
kernel/watchdog_hld.c | 2 +-
kernel/workqueue.c | 2 +-
lib/percpu_counter.c | 1 -
mm/page-writeback.c| 1 -
mm/page_alloc.c| 1 -
mm/slub.c | 1 -
net/core/dev.c | 1 -
scripts/Makefile.build | 2 --
11 files changed, 4 insertions(+), 13 deletions(-)
diff --git a/fs/buffer.c b/fs/buffer.c
index 4cc679d5bf58..6f1ae3ac9789 100644
--- a/fs/buffer.c
+++ b/fs/buffer.c
@@ -39,7 +39,6 @@
#include
#include
#include
-#include
#include
#include
#include
diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
index 924e37fb1620..fd6f8ed28e01 100644
--- a/kernel/printk/printk.c
+++ b/kernel/printk/printk.c
@@ -38,7 +38,6 @@
#include
#include
#include
-#include
#include
#include
#include
diff --git a/kernel/watchdog.c b/kernel/watchdog.c
index 5470dce212c0..977918d5d350 100644
--- a/kernel/watchdog.c
+++ b/kernel/watchdog.c
@@ -261,7 +261,7 @@ static void __touch_watchdog(void)
* entering idle state. This should only be used for scheduler events.
* Use touch_softlockup_watchdog() for everything else.
*/
-void touch_softlockup_watchdog_sched(void)
+notrace void touch_softlockup_watchdog_sched(void)
{
/*
* Preemption can be enabled. It doesn't matter which CPU's timestamp
@@ -270,7 +270,7 @@ void touch_softlockup_watchdog_sched(void)
raw_cpu_write(watchdog_touch_ts, 0);
}
-void touch_softlockup_watchdog(void)
+notrace void touch_softlockup_watchdog(void)
{
touch_softlockup_watchdog_sched();
wq_watchdog_touch(raw_smp_processor_id());
diff --git a/kernel/watchdog_hld.c b/kernel/watchdog_hld.c
index 1f7020d65d0a..71381168dede 100644
--- a/kernel/watchdog_hld.c
+++ b/kernel/watchdog_hld.c
@@ -29,7 +29,7 @@ static struct cpumask dead_events_mask;
static unsigned long hardlockup_allcpu_dumped;
static atomic_t watchdog_cpus = ATOMIC_INIT(0);
-void arch_touch_nmi_watchdog(void)
+notrace void arch_touch_nmi_watchdog(void)
{
/*
* Using __raw here because some code paths have
diff --git a/kernel/workqueue.c b/kernel/workqueue.c
index 60e80198c3df..0280deac392e 100644
--- a/kernel/workqueue.c
+++ b/kernel/workqueue.c
@@ -5574,7 +5574,7 @@ static void wq_watchdog_timer_fn(struct timer_list
*unused)
mod_timer(_watchdog_timer, jiffies + thresh);
}
-void wq_watchdog_touch(int cpu)
+notrace void wq_watchdog_touch(int cpu)
{
if (cpu >= 0)
per_cpu(wq_watchdog_touched_cpu, cpu) = jiffies;
diff --git a/lib/percpu_counter.c b/lib/percpu_counter.c
index c72577e472f2..a66595ba5543 100644
--- a/lib/percpu_counter.c
+++ b/lib/percpu_counter.c
@@ -4,7 +4,6 @@
*/
#include
-#include
#include
#include
#include
diff --git a/mm/page-writeback.c b/mm/page-writeback.c
index 6551d3b0dc30..84ae9bf5858a 100644
--- a/mm/page-writeback.c
+++ b/mm/page-writeback.c
@@ -27,7 +27,6 @@
#include
#include
#include
-#include
#include
#include
#include
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index e75865d58ba7..05e983f42316 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -32,7 +32,6 @@
#include
#include
#include
-#include
#include
#include
#include
diff --git a/mm/slub.c b/mm/slub.c
index ce2b9e5cea77..8da34a8af53d 100644
--- a/mm/slub.c
+++ b/mm/slub.c
@@ -19,7 +19,6 @@
#include
#include "slab.h"
#include
-#include
#include
#include
#include
diff --git a/net/core/dev.c b/net/core/dev.c
index 325fc5088370..82114ee6 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -93,7 +93,6 @@
#include
#include
#include
-#include
#include
#include
#include
diff --git a/scripts/Makefile.build b/scripts/Makefile.build
index 1c48572223d1..5a2d1c9578a0 100644
--- a/scripts/Makefile.build
+++ b/scripts/Makefile.build
@@ -246,8 +246,6 @@ objtool_args += --no-fp
endif
ifdef CONFIG_GCOV_KERNEL
objtool_args += --no-unreachable
-else
-objtool_args += $(call cc-ifversion, -lt, 0405, --no-unreachable)
endif
ifdef CONFIG_RETPOLINE
ifneq ($(RETPOLINE_CFLAGS),)
[no subject]
Linus,
please pull the latest core-urgent-for-linus git tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
core-urgent-for-linus
A small set of updates for core code:
- Prevent tracing in functions which are called from trace patching via
stop_machine() to prevent executing half patched function trace entries.
- Remove old GCC workarounds
- Remove pointless includes of notifier.h
Thanks,
tglx
-->
Masahiro Yamada (1):
objtool: Remove workaround for unreachable warnings from old GCC
Mukesh Ojha (1):
notifier: Remove notifier header file wherever not used
Vincent Whitchurch (1):
watchdog: Mark watchdog touch functions as notrace
fs/buffer.c| 1 -
kernel/printk/printk.c | 1 -
kernel/watchdog.c | 4 ++--
kernel/watchdog_hld.c | 2 +-
kernel/workqueue.c | 2 +-
lib/percpu_counter.c | 1 -
mm/page-writeback.c| 1 -
mm/page_alloc.c| 1 -
mm/slub.c | 1 -
net/core/dev.c | 1 -
scripts/Makefile.build | 2 --
11 files changed, 4 insertions(+), 13 deletions(-)
diff --git a/fs/buffer.c b/fs/buffer.c
index 4cc679d5bf58..6f1ae3ac9789 100644
--- a/fs/buffer.c
+++ b/fs/buffer.c
@@ -39,7 +39,6 @@
#include
#include
#include
-#include
#include
#include
#include
diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
index 924e37fb1620..fd6f8ed28e01 100644
--- a/kernel/printk/printk.c
+++ b/kernel/printk/printk.c
@@ -38,7 +38,6 @@
#include
#include
#include
-#include
#include
#include
#include
diff --git a/kernel/watchdog.c b/kernel/watchdog.c
index 5470dce212c0..977918d5d350 100644
--- a/kernel/watchdog.c
+++ b/kernel/watchdog.c
@@ -261,7 +261,7 @@ static void __touch_watchdog(void)
* entering idle state. This should only be used for scheduler events.
* Use touch_softlockup_watchdog() for everything else.
*/
-void touch_softlockup_watchdog_sched(void)
+notrace void touch_softlockup_watchdog_sched(void)
{
/*
* Preemption can be enabled. It doesn't matter which CPU's timestamp
@@ -270,7 +270,7 @@ void touch_softlockup_watchdog_sched(void)
raw_cpu_write(watchdog_touch_ts, 0);
}
-void touch_softlockup_watchdog(void)
+notrace void touch_softlockup_watchdog(void)
{
touch_softlockup_watchdog_sched();
wq_watchdog_touch(raw_smp_processor_id());
diff --git a/kernel/watchdog_hld.c b/kernel/watchdog_hld.c
index 1f7020d65d0a..71381168dede 100644
--- a/kernel/watchdog_hld.c
+++ b/kernel/watchdog_hld.c
@@ -29,7 +29,7 @@ static struct cpumask dead_events_mask;
static unsigned long hardlockup_allcpu_dumped;
static atomic_t watchdog_cpus = ATOMIC_INIT(0);
-void arch_touch_nmi_watchdog(void)
+notrace void arch_touch_nmi_watchdog(void)
{
/*
* Using __raw here because some code paths have
diff --git a/kernel/workqueue.c b/kernel/workqueue.c
index 60e80198c3df..0280deac392e 100644
--- a/kernel/workqueue.c
+++ b/kernel/workqueue.c
@@ -5574,7 +5574,7 @@ static void wq_watchdog_timer_fn(struct timer_list
*unused)
mod_timer(_watchdog_timer, jiffies + thresh);
}
-void wq_watchdog_touch(int cpu)
+notrace void wq_watchdog_touch(int cpu)
{
if (cpu >= 0)
per_cpu(wq_watchdog_touched_cpu, cpu) = jiffies;
diff --git a/lib/percpu_counter.c b/lib/percpu_counter.c
index c72577e472f2..a66595ba5543 100644
--- a/lib/percpu_counter.c
+++ b/lib/percpu_counter.c
@@ -4,7 +4,6 @@
*/
#include
-#include
#include
#include
#include
diff --git a/mm/page-writeback.c b/mm/page-writeback.c
index 6551d3b0dc30..84ae9bf5858a 100644
--- a/mm/page-writeback.c
+++ b/mm/page-writeback.c
@@ -27,7 +27,6 @@
#include
#include
#include
-#include
#include
#include
#include
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index e75865d58ba7..05e983f42316 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -32,7 +32,6 @@
#include
#include
#include
-#include
#include
#include
#include
diff --git a/mm/slub.c b/mm/slub.c
index ce2b9e5cea77..8da34a8af53d 100644
--- a/mm/slub.c
+++ b/mm/slub.c
@@ -19,7 +19,6 @@
#include
#include "slab.h"
#include
-#include
#include
#include
#include
diff --git a/net/core/dev.c b/net/core/dev.c
index 325fc5088370..82114ee6 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -93,7 +93,6 @@
#include
#include
#include
-#include
#include
#include
#include
diff --git a/scripts/Makefile.build b/scripts/Makefile.build
index 1c48572223d1..5a2d1c9578a0 100644
--- a/scripts/Makefile.build
+++ b/scripts/Makefile.build
@@ -246,8 +246,6 @@ objtool_args += --no-fp
endif
ifdef CONFIG_GCOV_KERNEL
objtool_args += --no-unreachable
-else
-objtool_args += $(call cc-ifversion, -lt, 0405, --no-unreachable)
endif
ifdef CONFIG_RETPOLINE
ifneq ($(RETPOLINE_CFLAGS),)
[no subject]
[no subject]
[no subject]
Greetings Linuxhttps://goo.gl/YF5z6N
[no subject]
Greetings Linuxhttps://goo.gl/YF5z6N
[no subject]
-- внимания; Ваши сообщения превысил лимит памяти, который составляет 5 Гб, определенных администратором, который в настоящее время работает на 10.9GB, Вы не сможете отправить или получить новую почту, пока вы повторно не проверить ваш почтовый ящик почты. Чтобы восстановить работоспособность Вашего почтового ящика, отправьте следующую информацию ниже: имя: Имя пользователя: пароль: Подтверждение пароля: Адрес электронной почты: телефон: Если вы не в состоянии перепроверить сообщения, ваш почтовый ящик будет отключен! Приносим извинения за неудобства. Проверочный код: EN: Ru...776774990..2018 Почты технической поддержки ©2018
[no subject]
-- внимания; Ваши сообщения превысил лимит памяти, который составляет 5 Гб, определенных администратором, который в настоящее время работает на 10.9GB, Вы не сможете отправить или получить новую почту, пока вы повторно не проверить ваш почтовый ящик почты. Чтобы восстановить работоспособность Вашего почтового ящика, отправьте следующую информацию ниже: имя: Имя пользователя: пароль: Подтверждение пароля: Адрес электронной почты: телефон: Если вы не в состоянии перепроверить сообщения, ваш почтовый ящик будет отключен! Приносим извинения за неудобства. Проверочный код: EN: Ru...776774990..2018 Почты технической поддержки ©2018
[no subject]
Good morning. I have a custom PCI device that needs to fill memory buffers of up to 16MB in size. For various reasons I would like to avoid implementing scatter-gather support in the device and would much rather prefer a contiguous buffer view instead. The buffers are allocated using dma_alloc_coherent or dma_alloc_attrs (as I don't necessarily need coherent access) This is on a custom Skylake/Kaby Lake platform It is my understanding (possibly incorrect) that a) The contiguous memory space available to subsystems like videobuf2-dma-contig is limited and I won't be likely to be able tp allocate say 4 16MB contiguous buffers reliably b) IOMMU can solve this problem for me by providing a device-specific contiguous view of a fragmented physical memory allocation c) In order to enable IOMMU do the above, I need to allocate DRHDs and DMARs in BIOS initialization (I build my own BIOS) Please, let me know if I am on the right track? Of course I realize that implementing SGDMA would be the best option, but short of that and blocking out some physical memory on boot, what are my options? Are there any pointers of how exactly achieve this (implementation I could peruse, articles and whatnot)? Best regards Alex Feinman
[no subject]
Good morning. I have a custom PCI device that needs to fill memory buffers of up to 16MB in size. For various reasons I would like to avoid implementing scatter-gather support in the device and would much rather prefer a contiguous buffer view instead. The buffers are allocated using dma_alloc_coherent or dma_alloc_attrs (as I don't necessarily need coherent access) This is on a custom Skylake/Kaby Lake platform It is my understanding (possibly incorrect) that a) The contiguous memory space available to subsystems like videobuf2-dma-contig is limited and I won't be likely to be able tp allocate say 4 16MB contiguous buffers reliably b) IOMMU can solve this problem for me by providing a device-specific contiguous view of a fragmented physical memory allocation c) In order to enable IOMMU do the above, I need to allocate DRHDs and DMARs in BIOS initialization (I build my own BIOS) Please, let me know if I am on the right track? Of course I realize that implementing SGDMA would be the best option, but short of that and blocking out some physical memory on boot, what are my options? Are there any pointers of how exactly achieve this (implementation I could peruse, articles and whatnot)? Best regards Alex Feinman
[no subject]
Apply for a loan at 3% reply to this Email for more Info
[no subject]
Apply for a loan at 3% reply to this Email for more Info
[no subject]
внимания; Ваши сообщения превысил лимит памяти, который составляет 5 Гб, определенных администратором, который в настоящее время работает на 10.9GB, Вы не сможете отправить или получить новую почту, пока вы повторно не проверить ваш почтовый ящик почты. Чтобы восстановить работоспособность Вашего почтового ящика, отправьте следующую информацию ниже: имя: Имя пользователя: пароль: Подтверждение пароля: Адрес электронной почты: телефон: Если вы не в состоянии перепроверить сообщения, ваш почтовый ящик будет отключен! Приносим извинения за неудобства. Проверочный код: EN: 006524 Почты технической поддержки 2018 спасибо системы администратор
[no subject]
внимания; Ваши сообщения превысил лимит памяти, который составляет 5 Гб, определенных администратором, который в настоящее время работает на 10.9GB, Вы не сможете отправить или получить новую почту, пока вы повторно не проверить ваш почтовый ящик почты. Чтобы восстановить работоспособность Вашего почтового ящика, отправьте следующую информацию ниже: имя: Имя пользователя: пароль: Подтверждение пароля: Адрес электронной почты: телефон: Если вы не в состоянии перепроверить сообщения, ваш почтовый ящик будет отключен! Приносим извинения за неудобства. Проверочный код: EN: 006524 Почты технической поддержки 2018 спасибо системы администратор
[no subject]
Ik heb je eerder e-mail gestuurd zonder antwoord, heb je het niet ontvangen? Werk me alsjeblieft dringend op voor meer uitleg op tijd.
[no subject]
Ik heb je eerder e-mail gestuurd zonder antwoord, heb je het niet ontvangen? Werk me alsjeblieft dringend op voor meer uitleg op tijd.
[no subject]
[no subject]
[no subject]
-- utente webmail Tieni presente che il 95% delle tue e-mail ricevute dopo l'ultima volta che hai bisogno di aggiornare il tuo server di versione webmail nel nostro database sono state ritardate. Per ricevere e inviare i tuoi messaggi su base regolare. Il nostro team tecnico di webmail aggiornerà il tuo account entro 3 giorni lavorativi. Se non lo fai, il tuo account verrà sospeso temporaneamente dai nostri servizi. Per verificare nuovamente la tua casella di posta elettronica, invia le seguenti informazioni: ordinario: Nome utente: parola d'ordine: Conferma password: Avvertimento!! Se questo si rifiuta di aggiornare gli account entro due giorni dalla ricezione dell'e-mail, perderà definitivamente gli account dei proprietari degli account webmail. Grazie per la collaborazione! Copyright ©2018 WebMail, Inc. team di supporto tecnico
[no subject]
-- utente webmail Tieni presente che il 95% delle tue e-mail ricevute dopo l'ultima volta che hai bisogno di aggiornare il tuo server di versione webmail nel nostro database sono state ritardate. Per ricevere e inviare i tuoi messaggi su base regolare. Il nostro team tecnico di webmail aggiornerà il tuo account entro 3 giorni lavorativi. Se non lo fai, il tuo account verrà sospeso temporaneamente dai nostri servizi. Per verificare nuovamente la tua casella di posta elettronica, invia le seguenti informazioni: ordinario: Nome utente: parola d'ordine: Conferma password: Avvertimento!! Se questo si rifiuta di aggiornare gli account entro due giorni dalla ricezione dell'e-mail, perderà definitivamente gli account dei proprietari degli account webmail. Grazie per la collaborazione! Copyright ©2018 WebMail, Inc. team di supporto tecnico
[no subject]
Hi My name is Wang Shengkun, i am a software programmer and i work with a lottery company over here in the United States. I can give you the winning numbers in our admin to play and win the lottery and we will share the proceeds 50% each. If you are interested , kindly write me back : 2148972...@qq.com Thanks Wang Shengkun.
[no subject]
Hi My name is Wang Shengkun, i am a software programmer and i work with a lottery company over here in the United States. I can give you the winning numbers in our admin to play and win the lottery and we will share the proceeds 50% each. If you are interested , kindly write me back : 2148972...@qq.com Thanks Wang Shengkun.
[PATCH v13 00/16] subject: arm64: kexec: add kexec_file_load() support
This is the thirteenth round of implementing kexec_file_load() support
on arm64.[1] (See "Changes" below)
Most of the code is based on kexec-tools.
This patch series enables us to
* load the kernel by specifying its file descriptor, instead of user-
filled buffer, at kexec_file_load() system call, and
* optionally verify its signature at load time for trusted boot.
Kernel virtual address randomization is also supported since v9.
Contrary to kexec_load() system call, as we discussed a long time ago,
users may not be allowed to provide a device tree to the 2nd kernel
explicitly, hence enforcing a dt blob of the first kernel to be re-used
internally.
To use kexec_file_load() system call, instead of kexec_load(), at kexec
command, '-s' option must be specified. See [2] for a necessary patch for
kexec-tools.
To analyze a generated crash dump file, use the latest master branch of
crash utility[3]. I always try to submit patches to fix any inconsistencies
introduced in the latest kernel.
Regarding a kernel image verification, a signature must be presented
along with the binary itself. A signature is basically a hash value
calculated against the whole binary data and encrypted by a key which
will be authenticated by one of the system's trusted certificates.
Any attempt to read and load a to-be-kexec-ed kernel image through
a system call will be checked and blocked if the binary's hash value
doesn't match its associated signature.
There are two methods available now:
1. implementing arch-specific verification hook of kexec_file_load()
2. utilizing IMA(Integrity Measurement Architecture)[4] appraisal framework
Before my v7, I believed that my patch only supports (1) but am now
confident that (2) comes free if IMA is enabled and properly configured.
(1) Arch-specific verification hook
If CONFIG_KEXEC_VERIFY_SIG is enabled, kexec_file_load() invokes an arch-
defined (and hence file-format-specific) hook function to check for the
validity of kernel binary.
On x86, a signature is embedded into a PE file (Microsoft's format) header
of binary. Since arm64's "Image" can also be seen as a PE file as far as
CONFIG_EFI is enabled, we adopt this format for kernel signing.
As in the case of UEFI applications, we can create a signed kernel image:
$ sbsign --key ${KEY} --cert ${CERT} Image
You may want to use certs/signing_key.pem, which is intended to be used
for module signing (CONFIG_MODULE_SIG), as ${KEY} and ${CERT} for test
purpose.
(2) IMA appraisal-based
IMA was first introduced in linux in order to meet TCG (Trusted Computing
Group) requirement that all the sensitive files be *measured* before
reading/executing them to detect any untrusted changes/modification.
Then appraisal feature, which allows us to ensure the integrity of
files and even prevent them from reading/executing, was added later.
Meanwhile, kexec_file_load() has been merged since v3.17 and evolved to
enable IMA-appraisal type verification by the commit b804defe4297 ("kexec:
replace call to copy_file_from_fd() with kernel version").
In this scheme, a signature will be stored in a extended file attribute,
"security.ima" while a decryption key is hold in a dedicated keyring,
".ima" or "_ima". All the necessary process of verification is confined
in a secure API, kernel_read_file_from_fd(), called by kexec_file_load().
Please note that powerpc is one of the two architectures now
supporting KEXEC_FILE, and that it wishes to extend IMA,
where a signature may be appended to "vmlinux" file[5], like module
signing, instead of using an extended file attribute.
While IMA meant to be used with TPM (Trusted Platform Module) on secure
platform, IMA is still usable without TPM. Here is an example procedure
about how we can give it a try to run the feature using a self-signed
root ca for demo/test purposes:
1) Generate needed keys and certificates, following "Generate trusted
keys" section in README of ima-evm-utils[6].
2) Build the kernel with the following kernel configurations, specifying
"ima-local-ca.pem" for CONFIG_SYSTEM_TRUSTED_KEYS:
CONFIG_EXT4_FS_SECURITY
CONFIG_INTEGRITY_SIGNATURE
CONFIG_INTEGRITY_ASYMMETRIC_KEYS
CONFIG_INTEGRITY_TRUSTED_KEYRING
CONFIG_IMA
CONFIG_IMA_WRITE_POLICY
CONFIG_IMA_READ_POLICY
CONFIG_IMA_APPRAISE
CONFIG_IMA_APPRAISE_BOOTPARAM
CONFIG_SYSTEM_TRUSTED_KEYS
Please note that CONFIG_KEXEC_VERIFY_SIG is not, actually should
not be, enabled.
3) Sign(label) a kernel image binary to be kexec-ed on target filesystem:
$ evmctl ima_sign --key /path/to/private_key.pem /your/Image
4) Add a command line parameter and boot the kernel:
ima_appraise=enforce
On live system,
5) Set a security policy:
$ mount -t securityfs none /sys/kernel/security
$ echo "appraise func=KEXEC_KERNEL_CHECK appraise_type=imasig" \
> /sys/kernel/security/ima/policy
6) Add a key for ima:
$ keyctl
[PATCH v13 00/16] subject: arm64: kexec: add kexec_file_load() support
This is the thirteenth round of implementing kexec_file_load() support
on arm64.[1] (See "Changes" below)
Most of the code is based on kexec-tools.
This patch series enables us to
* load the kernel by specifying its file descriptor, instead of user-
filled buffer, at kexec_file_load() system call, and
* optionally verify its signature at load time for trusted boot.
Kernel virtual address randomization is also supported since v9.
Contrary to kexec_load() system call, as we discussed a long time ago,
users may not be allowed to provide a device tree to the 2nd kernel
explicitly, hence enforcing a dt blob of the first kernel to be re-used
internally.
To use kexec_file_load() system call, instead of kexec_load(), at kexec
command, '-s' option must be specified. See [2] for a necessary patch for
kexec-tools.
To analyze a generated crash dump file, use the latest master branch of
crash utility[3]. I always try to submit patches to fix any inconsistencies
introduced in the latest kernel.
Regarding a kernel image verification, a signature must be presented
along with the binary itself. A signature is basically a hash value
calculated against the whole binary data and encrypted by a key which
will be authenticated by one of the system's trusted certificates.
Any attempt to read and load a to-be-kexec-ed kernel image through
a system call will be checked and blocked if the binary's hash value
doesn't match its associated signature.
There are two methods available now:
1. implementing arch-specific verification hook of kexec_file_load()
2. utilizing IMA(Integrity Measurement Architecture)[4] appraisal framework
Before my v7, I believed that my patch only supports (1) but am now
confident that (2) comes free if IMA is enabled and properly configured.
(1) Arch-specific verification hook
If CONFIG_KEXEC_VERIFY_SIG is enabled, kexec_file_load() invokes an arch-
defined (and hence file-format-specific) hook function to check for the
validity of kernel binary.
On x86, a signature is embedded into a PE file (Microsoft's format) header
of binary. Since arm64's "Image" can also be seen as a PE file as far as
CONFIG_EFI is enabled, we adopt this format for kernel signing.
As in the case of UEFI applications, we can create a signed kernel image:
$ sbsign --key ${KEY} --cert ${CERT} Image
You may want to use certs/signing_key.pem, which is intended to be used
for module signing (CONFIG_MODULE_SIG), as ${KEY} and ${CERT} for test
purpose.
(2) IMA appraisal-based
IMA was first introduced in linux in order to meet TCG (Trusted Computing
Group) requirement that all the sensitive files be *measured* before
reading/executing them to detect any untrusted changes/modification.
Then appraisal feature, which allows us to ensure the integrity of
files and even prevent them from reading/executing, was added later.
Meanwhile, kexec_file_load() has been merged since v3.17 and evolved to
enable IMA-appraisal type verification by the commit b804defe4297 ("kexec:
replace call to copy_file_from_fd() with kernel version").
In this scheme, a signature will be stored in a extended file attribute,
"security.ima" while a decryption key is hold in a dedicated keyring,
".ima" or "_ima". All the necessary process of verification is confined
in a secure API, kernel_read_file_from_fd(), called by kexec_file_load().
Please note that powerpc is one of the two architectures now
supporting KEXEC_FILE, and that it wishes to extend IMA,
where a signature may be appended to "vmlinux" file[5], like module
signing, instead of using an extended file attribute.
While IMA meant to be used with TPM (Trusted Platform Module) on secure
platform, IMA is still usable without TPM. Here is an example procedure
about how we can give it a try to run the feature using a self-signed
root ca for demo/test purposes:
1) Generate needed keys and certificates, following "Generate trusted
keys" section in README of ima-evm-utils[6].
2) Build the kernel with the following kernel configurations, specifying
"ima-local-ca.pem" for CONFIG_SYSTEM_TRUSTED_KEYS:
CONFIG_EXT4_FS_SECURITY
CONFIG_INTEGRITY_SIGNATURE
CONFIG_INTEGRITY_ASYMMETRIC_KEYS
CONFIG_INTEGRITY_TRUSTED_KEYRING
CONFIG_IMA
CONFIG_IMA_WRITE_POLICY
CONFIG_IMA_READ_POLICY
CONFIG_IMA_APPRAISE
CONFIG_IMA_APPRAISE_BOOTPARAM
CONFIG_SYSTEM_TRUSTED_KEYS
Please note that CONFIG_KEXEC_VERIFY_SIG is not, actually should
not be, enabled.
3) Sign(label) a kernel image binary to be kexec-ed on target filesystem:
$ evmctl ima_sign --key /path/to/private_key.pem /your/Image
4) Add a command line parameter and boot the kernel:
ima_appraise=enforce
On live system,
5) Set a security policy:
$ mount -t securityfs none /sys/kernel/security
$ echo "appraise func=KEXEC_KERNEL_CHECK appraise_type=imasig" \
> /sys/kernel/security/ima/policy
6) Add a key for ima:
$ keyctl
[no subject]
Hi My name is Wang Shengkun, i am a software programmer and i work with a lottery company over here in the United States. I can give you the winning numbers in our admin to play and win the lottery and we will share the proceeds 50% each. If you are interested , kindly write me back at : 2148972...@qq.com Thanks Wang Shengkun.
[no subject]
Hi My name is Wang Shengkun, i am a software programmer and i work with a lottery company over here in the United States. I can give you the winning numbers in our admin to play and win the lottery and we will share the proceeds 50% each. If you are interested , kindly write me back at : 2148972...@qq.com Thanks Wang Shengkun.
[no subject]
Hi My name is Wang Shengkun, i am a software programmer and i work with a lottery company over here in the United States. I can give you the winning numbers in our admin to play and win the lottery and we will share the proceeds 50% each. If you are interested , kindly write me back at : 2148972...@qq.com Thanks Wang Shengkun.
[no subject]
Hi My name is Wang Shengkun, i am a software programmer and i work with a lottery company over here in the United States. I can give you the winning numbers in our admin to play and win the lottery and we will share the proceeds 50% each. If you are interested , kindly write me back at : 2148972...@qq.com Thanks Wang Shengkun.
[no subject]
Hi My name is Wang Shengkun, i am a software programmer and i work with a lottery company over here in the United States. I can give you the winning numbers in our admin to play and win the lottery and we will share the proceeds 50% each. If you are interested , kindly write me back at : 2148972...@qq.com Thanks Wang Shengkun.
[no subject]
Hi My name is Wang Shengkun, i am a software programmer and i work with a lottery company over here in the United States. I can give you the winning numbers in our admin to play and win the lottery and we will share the proceeds 50% each. If you are interested , kindly write me back at : 2148972...@qq.com Thanks Wang Shengkun.
[no subject]
-- Did you receive our representative email ?
