* [RFC v3 PATCH 0/2] Introduce Security Version to EFI Stub
From: Ingo Molnar @ 2017-12-07 6:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171207015903.jaos5siysggzz4nc@GaryWorkstation>
* Gary Lin <glin@suse.com> wrote:
> On Wed, Dec 06, 2017 at 07:37:34PM +0100, Ingo Molnar wrote:
> >
> > * Gary Lin <glin@suse.com> wrote:
> >
> > > On Tue, Dec 05, 2017 at 04:14:26PM -0500, Josh Boyer wrote:
> > > > On Tue, Dec 5, 2017 at 5:01 AM, Gary Lin <glin@suse.com> wrote:
> > > > > The series of patches introduce Security Version to EFI stub.
> > > > >
> > > > > Security Version is a monotonically increasing number and designed to
> > > > > prevent the user from loading an insecure kernel accidentally. The
> > > > > bootloader maintains a list of security versions corresponding to
> > > > > different distributions. After fixing a critical vulnerability, the
> > > > > distribution kernel maintainer bumps the "version", and the bootloader
> > > > > updates the list automatically. When the user tries to load a kernel
> > > > > with a lower security version, the bootloader shows a warning prompt
> > > > > to notify the user the potential risk.
> > > >
> > > > If a distribution releases a kernel with a higher security version and
> > > > that it automatically updated on boot, what happens if that kernel
> > > > contains a different bug that causes it to fail to boot or break
> > > > critical functionality? At that point, the user's machine would be in
> > > > a state where the higher security version is enforced but the only
> > > > kernel that provides that is broken. Wouldn't that make a bad
> > > > situation even worse by now requiring manual acceptance of the older
> > > > SV kernel boot physically at the machine?
> > > >
> > > > I feel like I'm missing a detail here or something.
> > > >
> > > If the new kernel fails to boot, then the user has to choose the kernel
> > > manually anyway, and there will be an option in the warning prompt to
> > > lower SV.
> >
> > And what if the firmware does not support a lowering of the SV?
> >
> The SV list is manipulated by the bootloader, and the firmware only
> provides the interface to the storage, i.e. non-volatile flash.
What about systems where the bootloader is part of the system and users only have
the ability to provide kernel images, but no ability to change the boot loader?
Thanks,
Ingo
^ permalink raw reply
* [PATCH v2 3/3] ARM: davinci: fix mmc entries in DM365's eDMA slaves table
From: Sekhar Nori @ 2017-12-07 6:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171205123458.97837-4-amery@hanoverdisplays.com>
Hi,
On Tuesday 05 December 2017 06:04 PM, Alejandro Mery wrote:
> Signed-off-by: Alejandro Mery <amery@hanoverdisplays.com>
Patch looks good, but please resubmit with patch description. Patch
description should be readable independent of headline so please add it
even if its just restating what is present in the headline.
Also, please add a Fixes tag.
Fixes: 0c750e1fe481 ("ARM: davinci: dm365: Add dma_slave_map to edma")
You can base the next version on fixes branch of my tree[1].
Thanks,
Sekhar
[1] git://git.kernel.org/pub/scm/linux/kernel/git/nsekhar/linux-davinci.git
> ---
> arch/arm/mach-davinci/dm365.c | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm/mach-davinci/dm365.c b/arch/arm/mach-davinci/dm365.c
> index 103316f01a22..5ace9380626a 100644
> --- a/arch/arm/mach-davinci/dm365.c
> +++ b/arch/arm/mach-davinci/dm365.c
> @@ -868,10 +868,10 @@ static const struct dma_slave_map dm365_edma_map[] = {
> { "spi_davinci.0", "rx", EDMA_FILTER_PARAM(0, 17) },
> { "spi_davinci.3", "tx", EDMA_FILTER_PARAM(0, 18) },
> { "spi_davinci.3", "rx", EDMA_FILTER_PARAM(0, 19) },
> - { "dm6441-mmc.0", "rx", EDMA_FILTER_PARAM(0, 26) },
> - { "dm6441-mmc.0", "tx", EDMA_FILTER_PARAM(0, 27) },
> - { "dm6441-mmc.1", "rx", EDMA_FILTER_PARAM(0, 30) },
> - { "dm6441-mmc.1", "tx", EDMA_FILTER_PARAM(0, 31) },
> + { "da830-mmc.0", "rx", EDMA_FILTER_PARAM(0, 26) },
> + { "da830-mmc.0", "tx", EDMA_FILTER_PARAM(0, 27) },
> + { "da830-mmc.1", "rx", EDMA_FILTER_PARAM(0, 30) },
> + { "da830-mmc.1", "tx", EDMA_FILTER_PARAM(0, 31) },
> };
>
> static struct edma_soc_info dm365_edma_pdata = {
> --
> 2.15.0
>
^ permalink raw reply
* [PATCH v2 0/3] ARM: davinci: fix eDMA for DM365
From: Sekhar Nori @ 2017-12-07 6:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171205123458.97837-1-amery@hanoverdisplays.com>
Hi Alejandro,
On Tuesday 05 December 2017 06:04 PM, Alejandro Mery wrote:
> Hi, as an intermediate step toward migrating a davinci dm365 based product from 2.6.32.71
> to 4.14(.3+) I'm trying to get the dm365 evm (evaluation board) to work
Thanks for trying the mainline kernel on this device!
For the next time, when submitting another version, please send as an
independent series, not as reply to the the previous post.
Many maintainers will ignore old threads where comments have already
been provided. Sending fresh patches in reply to old thread just
increases the chance of patches getting lost.
Thanks,
Sekhar
^ permalink raw reply
* [PATCH 2/2] arm64: allwinner: a64: bananapi-m64: add usb otg
From: Jagan Teki @ 2017-12-07 6:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGb2v67uFnV+m1Ub7rFVGhkv0HKD4ukpQFtJ1pqRi2vf4F=tFA@mail.gmail.com>
On Thu, Dec 7, 2017 at 8:54 AM, Chen-Yu Tsai <wens@csie.org> wrote:
> On Thu, Dec 7, 2017 at 1:51 AM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
>> usb otg on bananapi-m64 has configured with USB-ID with PH9
>> and USB-DRVVBUS attached with dcdc1 regulatort.
>
> That is not how you read the schematic...
>
> Intersecting lines that are tied together will have a dot representing
> the connection. The DCDC1 line is a pull-up for the ID pin. This is very
> clear because it has a resistor connected in series.
>
> VBUS for OTG is controlled by the IC displayed to the right in the
> schematic, which is powered from 5V, and controlled by the DRVVBUS
> pin from the PMIC. Please take a look at how the A31/A33/A83T board
> dts files represent this.
This is where I confused, USB-DRVVBUS is connected to pin 51 of PMIC
if we add 5v regulator how can configure gpio number for this? I saw
sun8i-a33-olinuxino.dts which is also similar but it has gpio = <&pio
1 9 GPIO_ACTIVE_HIGH>;
thanks!
--
Jagan Teki
Free Software Engineer | www.openedev.com
U-Boot, Linux | Upstream Maintainer
Hyderabad, India.
^ permalink raw reply
* [PATCH 2/2] arm64: allwinner: a64: bananapi-m64: add usb otg
From: Chen-Yu Tsai @ 2017-12-07 6:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAD6G_RR-VccHjdrXs55=C50OvDEr96c7axtbR0eKp2THFNx6sg@mail.gmail.com>
On Thu, Dec 7, 2017 at 2:18 PM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
> On Thu, Dec 7, 2017 at 8:54 AM, Chen-Yu Tsai <wens@csie.org> wrote:
>> On Thu, Dec 7, 2017 at 1:51 AM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
>>> usb otg on bananapi-m64 has configured with USB-ID with PH9
>>> and USB-DRVVBUS attached with dcdc1 regulatort.
>>
>> That is not how you read the schematic...
>>
>> Intersecting lines that are tied together will have a dot representing
>> the connection. The DCDC1 line is a pull-up for the ID pin. This is very
>> clear because it has a resistor connected in series.
>>
>> VBUS for OTG is controlled by the IC displayed to the right in the
>> schematic, which is powered from 5V, and controlled by the DRVVBUS
>> pin from the PMIC. Please take a look at how the A31/A33/A83T board
>> dts files represent this.
>
> This is where I confused, USB-DRVVBUS is connected to pin 51 of PMIC
> if we add 5v regulator how can configure gpio number for this? I saw
>From the axp20x bindings:
- x-powers,drive-vbus-en: boolean, set this when the N_VBUSEN pin is
used as an output pin to control an external
regulator to drive the OTG VBus, rather then
as an input pin which signals whether the
board is driving OTG VBus or not.
(axp221 / axp223 / axp813 only)
Setting this allows you to use the "drivevbus" regulator under the PMIC.
As I said, look at how other boards are doing it.
> sun8i-a33-olinuxino.dts which is also similar but it has gpio = <&pio
> 1 9 GPIO_ACTIVE_HIGH>;
I have no idea where you saw this. It does not exist in my tree.
Why don't you just trace backwards from the usb0_vbus-supply property
under the usbphy node, and see where it all leads.
ChenYu
^ permalink raw reply
* [PATCH v8 7/7] arm64: kvm: handle SError Interrupt by categorization
From: gengdongjiu @ 2017-12-07 6:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5A283F26.3020507@arm.com>
Hi James,
On 2017/12/7 3:04, James Morse wrote:
> Hi gengdongjiu,
>
> On 06/12/17 10:26, gengdongjiu wrote:
>> On 2017/11/15 0:00, James Morse wrote:
>>>> + * error has not been propagated
>>>> + */
>>>> + run->exit_reason = KVM_EXIT_EXCEPTION;
>>>> + run->ex.exception = ESR_ELx_EC_SERROR;
>>>> + run->ex.error_code = KVM_SEI_SEV_RECOVERABLE;
>>>> + return 0;
>>> We should not pass RAS notifications to user space. The kernel either handles
>>> them, or it panics(). User space shouldn't even know if the kernel supports RAS
>>> until it gets an MCEERR signal.
>>>
>>> You're making your firmware-first notification an EL3->EL0 signal, bypassing the OS.
>>>
>>> If we get a RAS SError and there are no CPER records or values in the ERR nodes,
>>> we should panic as it looks like the CPU/firmware is broken. (spurious RAS errors)
>
>> do you think whether we need to set the guest ESR by user space? if need, I need to
>> notify user space that there is a SError happen and need to set ESR for guest in some place of
>> KVM.
>
> I think you are still coming from a world where user-space gets raw RAS
> notifications via KVM. This should not happen because the notification method is
> private to firmware and the kernel. KVM is just in the way when a guest is running.
>
> Notifications reaching KVM should be plumbed into the APEI-firmware-first-code
> or eventually, a kernel-first mechanism if APEI doesn't 'claim' them.
>
> The kernel RAS code may signal user-space with the symptoms of the error, and
> user-space may decided to generate a new RAS notification for the guest.
>
> This should function in exactly the same way, regardless of which notification
> method is in use between the kernel and firmware. (its the only way to make this
> future-proof).
>
> Which notification user-space chooses to use entirely depends on what (if
> anything) it advertised to the guest in the HEST. User-space has to be in
> control of triggering any SError, not just overriding the ESR when KVM has
> decided it wants to kill the guest.
thanks, I will explain more.
>
>
>> so here I return a error code to user space. you mean we should not pass RAS notifications
>> to user space, so could you give some suggestion how to notify user space to set guest ESR.
>
> KVM shouldn't give the guest an SError when it takes a RAS notification, it
> should pass the notification to the kernel RAS code. It only needs to 'fall
> through' to some default cause if both APEI and kernel-first deny-all-knowledge
> of this notification.
>
>
> The end-to-end flow is then (assuming no-VHE):
> (1)An error occurs, taking the CPU to EL3.
> EL3: triage the error, generate CPER, notify the OS
> EL2: KVM takes the notification, exits the guest, returns to host EL1.
> EL1: KVM handle_exit() calls APEI to handle the error.
> This is the end of KVMs involvement in RAS - its just plumbing.
>
> (2)APEI processes the CPER records and signals affected processes.
> If KVM's user-space is affected, KVM will spot the pending signal when it goes
> to re-enter the guest, and exit to user-space instead.
> Qemu takes the SIGBUS_MCEERR_A{O,R}.
>
> (3) Qemu decides it wants to hand the guest a RAS error, it populates the CPER
> records (in memory only Qemu knows about), then drives the KVM API to make the
> appropriate notification appear.
>
>
> (1) only happens if the guest was running when the error arrived. GHES has ~4
> flavours of IRQ which may be used to describe corruption in guest memory. Steps
> (2) and (3) are exactly the same in this case.
>
> Qemu may decide to trigger RAS errors all by itself, (probably for testing and
> debugging), in which case (1) and (2) don't happen, but (3), is exactly the same.
>
>
> This way platform-firmware/host-kernel can use kernel-first or firmware-first
> with any of the notifications, independently from Qemu/guest-kernel making a
> different kernel-first or firmware-first with different notifications.
>
> Passing information out of KVM breaks this, forcing Qemu to know about the
> mechanism platform-firmware is using.
>
>
> We need to tackle (1) and (3) separately. For (3) we need some API that lets
> Qemu _trigger_ an SError in the guest, with a specified ESR. But, we don't have
> a way of migrating pending SError yet... which is where I got stuck last time I
> was looking at this.
I understand you most idea.
But In the Qemu one signal type can only correspond to one behavior, can not correspond to two behaviors,
otherwise Qemu will do not know how to do.
For the Qemu, if it receives the SIGBUS_MCEERR_AR signal, it will populate the CPER
records and inject a SEA to guest through KVM IOCTL "KVM_SET_ONE_REG"; if receives the SIGBUS_MCEERR_AO
signal, it will record the CPER and trigger a IRQ to notify guest, as shown below:
SIGBUS_MCEERR_AR trigger Synchronous External Abort.
SIGBUS_MCEERR_AO trigger GPIO IRQ.
For the SIGBUS_MCEERR_AO and SIGBUS_MCEERR_AR, we have already specify trigger method, which all
not involve _trigger_ an SError.
so there is no chance for Qemu to trigger the SError when gets the SIGBUS_MCEERR_A{O,R}.
>
>
>
> James
>
> .
>
^ permalink raw reply
* [PATCH 0/2] CQSPI: Add direct mode support
From: Vignesh R @ 2017-12-07 6:38 UTC (permalink / raw)
To: linux-arm-kernel
This patch series enables use Direct access controller on Cadence QSPI
which helps in accessing QSPI flash in memory mapped mode.
On TI platforms, this mode has higher throughput compared to indirect
access mode.
Tested on TI's 66AK2G GP EVM.
It would be great if this patch series could be tested SoCFPGA as well.
Although, this patch should have no effect on SoCFPGA platforms as driver
continues to use indirect mode when direct access memory window is less
than size of connected flash.
Vignesh R (2):
mtd: spi-nor: cadence-quadspi: Refactor indirect read/write sequence.
mtd: spi-nor: cadence-quadspi: Add support for direct access mode
drivers/mtd/spi-nor/cadence-quadspi.c | 75 ++++++++++++++++++++++++++++-------
1 file changed, 60 insertions(+), 15 deletions(-)
--
2.15.1
^ permalink raw reply
* [PATCH 1/2] mtd: spi-nor: cadence-quadspi: Refactor indirect read/write sequence.
From: Vignesh R @ 2017-12-07 6:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171207063804.29436-1-vigneshr@ti.com>
Move configuring of indirect read/write start address to
cqspi_indirect_*_execute() function and rename cqspi_indirect_*_setup()
function. This will help to reuse cqspi_indirect_*_setup() function for
supporting direct access mode.
Signed-off-by: Vignesh R <vigneshr@ti.com>
---
drivers/mtd/spi-nor/cadence-quadspi.c | 27 ++++++++++++---------------
1 file changed, 12 insertions(+), 15 deletions(-)
diff --git a/drivers/mtd/spi-nor/cadence-quadspi.c b/drivers/mtd/spi-nor/cadence-quadspi.c
index 75a2bc447a99..becc7d714ab8 100644
--- a/drivers/mtd/spi-nor/cadence-quadspi.c
+++ b/drivers/mtd/spi-nor/cadence-quadspi.c
@@ -450,8 +450,7 @@ static int cqspi_command_write_addr(struct spi_nor *nor,
return cqspi_exec_flash_cmd(cqspi, reg);
}
-static int cqspi_indirect_read_setup(struct spi_nor *nor,
- const unsigned int from_addr)
+static int cqspi_read_setup(struct spi_nor *nor)
{
struct cqspi_flash_pdata *f_pdata = nor->priv;
struct cqspi_st *cqspi = f_pdata->cqspi;
@@ -459,7 +458,6 @@ static int cqspi_indirect_read_setup(struct spi_nor *nor,
unsigned int dummy_clk = 0;
unsigned int reg;
- writel(from_addr, reg_base + CQSPI_REG_INDIRECTRDSTARTADDR);
reg = nor->read_opcode << CQSPI_REG_RD_INSTR_OPCODE_LSB;
reg |= cqspi_calc_rdreg(nor, nor->read_opcode);
@@ -493,8 +491,8 @@ static int cqspi_indirect_read_setup(struct spi_nor *nor,
return 0;
}
-static int cqspi_indirect_read_execute(struct spi_nor *nor,
- u8 *rxbuf, const unsigned n_rx)
+static int cqspi_indirect_read_execute(struct spi_nor *nor, u8 *rxbuf,
+ loff_t from_addr, const size_t n_rx)
{
struct cqspi_flash_pdata *f_pdata = nor->priv;
struct cqspi_st *cqspi = f_pdata->cqspi;
@@ -504,6 +502,7 @@ static int cqspi_indirect_read_execute(struct spi_nor *nor,
unsigned int bytes_to_read = 0;
int ret = 0;
+ writel(from_addr, reg_base + CQSPI_REG_INDIRECTRDSTARTADDR);
writel(remaining, reg_base + CQSPI_REG_INDIRECTRDBYTES);
/* Clear all interrupts. */
@@ -570,8 +569,7 @@ static int cqspi_indirect_read_execute(struct spi_nor *nor,
return ret;
}
-static int cqspi_indirect_write_setup(struct spi_nor *nor,
- const unsigned int to_addr)
+static int cqspi_write_setup(struct spi_nor *nor)
{
unsigned int reg;
struct cqspi_flash_pdata *f_pdata = nor->priv;
@@ -584,8 +582,6 @@ static int cqspi_indirect_write_setup(struct spi_nor *nor,
reg = cqspi_calc_rdreg(nor, nor->program_opcode);
writel(reg, reg_base + CQSPI_REG_RD_INSTR);
- writel(to_addr, reg_base + CQSPI_REG_INDIRECTWRSTARTADDR);
-
reg = readl(reg_base + CQSPI_REG_SIZE);
reg &= ~CQSPI_REG_SIZE_ADDRESS_MASK;
reg |= (nor->addr_width - 1);
@@ -593,8 +589,8 @@ static int cqspi_indirect_write_setup(struct spi_nor *nor,
return 0;
}
-static int cqspi_indirect_write_execute(struct spi_nor *nor,
- const u8 *txbuf, const unsigned n_tx)
+static int cqspi_indirect_write_execute(struct spi_nor *nor, loff_t to_addr,
+ const u8 *txbuf, const size_t n_tx)
{
const unsigned int page_size = nor->page_size;
struct cqspi_flash_pdata *f_pdata = nor->priv;
@@ -604,6 +600,7 @@ static int cqspi_indirect_write_execute(struct spi_nor *nor,
unsigned int write_bytes;
int ret;
+ writel(to_addr, reg_base + CQSPI_REG_INDIRECTWRSTARTADDR);
writel(remaining, reg_base + CQSPI_REG_INDIRECTWRBYTES);
/* Clear all interrupts. */
@@ -900,11 +897,11 @@ static ssize_t cqspi_write(struct spi_nor *nor, loff_t to,
if (ret)
return ret;
- ret = cqspi_indirect_write_setup(nor, to);
+ ret = cqspi_write_setup(nor);
if (ret)
return ret;
- ret = cqspi_indirect_write_execute(nor, buf, len);
+ ret = cqspi_indirect_write_execute(nor, to, buf, len);
if (ret)
return ret;
@@ -920,11 +917,11 @@ static ssize_t cqspi_read(struct spi_nor *nor, loff_t from,
if (ret)
return ret;
- ret = cqspi_indirect_read_setup(nor, from);
+ ret = cqspi_read_setup(nor);
if (ret)
return ret;
- ret = cqspi_indirect_read_execute(nor, buf, len);
+ ret = cqspi_indirect_read_execute(nor, buf, from, len);
if (ret)
return ret;
--
2.15.1
^ permalink raw reply related
* [PATCH 2/2] mtd: spi-nor: cadence-quadspi: Add support for direct access mode
From: Vignesh R @ 2017-12-07 6:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171207063804.29436-1-vigneshr@ti.com>
Cadence QSPI controller provides direct access mode through which flash
can be accessed in a memory-mapped IO mode. This enables read/write to
flash using memcpy*() functions. This mode provides higher throughput
for both read/write operations when compared to current indirect mode of
operation.
This patch therefore adds support to use QSPI in direct mode. If the
window reserved in SoC's memory map for MMIO access is less that of
flash size(like on most SoCFPGA variants), then the driver falls back
to indirect mode of operation.
On TI's 66AK2G SoC, with ARM running at 600MHz and QSPI at 96MHz
switching to direct mode improves read throughput from 3MB/s to 8MB/s.
Signed-off-by: Vignesh R <vigneshr@ti.com>
---
drivers/mtd/spi-nor/cadence-quadspi.c | 52 +++++++++++++++++++++++++++++++++--
1 file changed, 50 insertions(+), 2 deletions(-)
diff --git a/drivers/mtd/spi-nor/cadence-quadspi.c b/drivers/mtd/spi-nor/cadence-quadspi.c
index becc7d714ab8..f8721ed68bc6 100644
--- a/drivers/mtd/spi-nor/cadence-quadspi.c
+++ b/drivers/mtd/spi-nor/cadence-quadspi.c
@@ -58,6 +58,7 @@ struct cqspi_flash_pdata {
u8 data_width;
u8 cs;
bool registered;
+ bool use_direct_mode;
};
struct cqspi_st {
@@ -68,6 +69,7 @@ struct cqspi_st {
void __iomem *iobase;
void __iomem *ahb_base;
+ resource_size_t ahb_size;
struct completion transfer_complete;
struct mutex bus_mutex;
@@ -103,6 +105,7 @@ struct cqspi_st {
/* Register map */
#define CQSPI_REG_CONFIG 0x00
#define CQSPI_REG_CONFIG_ENABLE_MASK BIT(0)
+#define CQSPI_REG_CONFIG_ENB_DIR_ACC_CTRL BIT(7)
#define CQSPI_REG_CONFIG_DECODE_MASK BIT(9)
#define CQSPI_REG_CONFIG_CHIPSELECT_LSB 10
#define CQSPI_REG_CONFIG_DMA_MASK BIT(15)
@@ -569,6 +572,21 @@ static int cqspi_indirect_read_execute(struct spi_nor *nor, u8 *rxbuf,
return ret;
}
+static int cqspi_direct_read_execute(struct spi_nor *nor, u8 *rxbuf,
+ loff_t from_addr, const size_t len)
+{
+ struct cqspi_flash_pdata *f_pdata = nor->priv;
+ struct cqspi_st *cqspi = f_pdata->cqspi;
+ u32 reg;
+
+ reg = readl(cqspi->iobase + CQSPI_REG_CONFIG);
+ reg |= CQSPI_REG_CONFIG_ENB_DIR_ACC_CTRL;
+ writel(reg, cqspi->iobase + CQSPI_REG_CONFIG);
+ memcpy_fromio(rxbuf, cqspi->ahb_base + from_addr, len);
+
+ return 0;
+}
+
static int cqspi_write_setup(struct spi_nor *nor)
{
unsigned int reg;
@@ -671,6 +689,21 @@ static int cqspi_indirect_write_execute(struct spi_nor *nor, loff_t to_addr,
return ret;
}
+static int cqspi_direct_write_execute(struct spi_nor *nor, loff_t to_addr,
+ const u8 *txbuf, const size_t len)
+{
+ struct cqspi_flash_pdata *f_pdata = nor->priv;
+ struct cqspi_st *cqspi = f_pdata->cqspi;
+ u32 reg;
+
+ reg = readl(cqspi->iobase + CQSPI_REG_CONFIG);
+ reg |= CQSPI_REG_CONFIG_ENB_DIR_ACC_CTRL;
+ writel(reg, cqspi->iobase + CQSPI_REG_CONFIG);
+ memcpy_toio(cqspi->ahb_base + to_addr, txbuf, len);
+
+ return 0;
+}
+
static void cqspi_chipselect(struct spi_nor *nor)
{
struct cqspi_flash_pdata *f_pdata = nor->priv;
@@ -891,6 +924,7 @@ static int cqspi_set_protocol(struct spi_nor *nor, const int read)
static ssize_t cqspi_write(struct spi_nor *nor, loff_t to,
size_t len, const u_char *buf)
{
+ struct cqspi_flash_pdata *f_pdata = nor->priv;
int ret;
ret = cqspi_set_protocol(nor, 0);
@@ -901,7 +935,10 @@ static ssize_t cqspi_write(struct spi_nor *nor, loff_t to,
if (ret)
return ret;
- ret = cqspi_indirect_write_execute(nor, to, buf, len);
+ if (f_pdata->use_direct_mode)
+ ret = cqspi_direct_write_execute(nor, to, buf, len);
+ else
+ ret = cqspi_indirect_write_execute(nor, to, buf, len);
if (ret)
return ret;
@@ -911,6 +948,7 @@ static ssize_t cqspi_write(struct spi_nor *nor, loff_t to,
static ssize_t cqspi_read(struct spi_nor *nor, loff_t from,
size_t len, u_char *buf)
{
+ struct cqspi_flash_pdata *f_pdata = nor->priv;
int ret;
ret = cqspi_set_protocol(nor, 1);
@@ -921,7 +959,10 @@ static ssize_t cqspi_read(struct spi_nor *nor, loff_t from,
if (ret)
return ret;
- ret = cqspi_indirect_read_execute(nor, buf, from, len);
+ if (f_pdata->use_direct_mode)
+ ret = cqspi_direct_read_execute(nor, buf, from, len);
+ else
+ ret = cqspi_indirect_read_execute(nor, buf, from, len);
if (ret)
return ret;
@@ -1153,6 +1194,12 @@ static int cqspi_setup_flash(struct cqspi_st *cqspi, struct device_node *np)
goto err;
f_pdata->registered = true;
+
+ if (mtd->size <= cqspi->ahb_size) {
+ f_pdata->use_direct_mode = true;
+ dev_info(nor->dev, "using direct mode for %s\n",
+ mtd->name);
+ }
}
return 0;
@@ -1212,6 +1259,7 @@ static int cqspi_probe(struct platform_device *pdev)
dev_err(dev, "Cannot remap AHB address.\n");
return PTR_ERR(cqspi->ahb_base);
}
+ cqspi->ahb_size = resource_size(res_ahb);
init_completion(&cqspi->transfer_complete);
--
2.15.1
^ permalink raw reply related
* [PATCH 1/6] clk: stm32f4: pr_err() strings should end with newlines
From: Stephen Boyd @ 2017-12-07 6:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <d5b9943c076a8ad168d9b0b3ba3aec7c9b8d7d06.1511505932.git.arvind.yadav.cs@gmail.com>
On 11/24, Arvind Yadav wrote:
> pr_err() messages should end with a new-line to avoid other messages
> being concatenated.
>
> Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
> ---
Applied to clk-next
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH 2/6] clk: lpc32xx: pr_err() strings should end with newlines
From: Stephen Boyd @ 2017-12-07 6:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1dddfd71153339875c7bedf6e562483607180a4d.1511505932.git.arvind.yadav.cs@gmail.com>
On 11/24, Arvind Yadav wrote:
> pr_err() messages should end with a new-line to avoid other messages
> being concatenated.
>
> Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
> ---
Applied to clk-next
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH 3/6] clk: SPEAr: pr_err() strings should end with newlines
From: Stephen Boyd @ 2017-12-07 6:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <03a5ce213323863375e1fb3f85c0c3cc8c921a41.1511505932.git.arvind.yadav.cs@gmail.com>
On 11/24, Arvind Yadav wrote:
> pr_err() messages should end with a new-line to avoid other messages
> being concatenated.
>
> Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
> ---
Applied to clk-next
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH 4/6] SPEAr: clk: pr_err() strings should end with newlines
From: Stephen Boyd @ 2017-12-07 6:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <35a712ed8ee10491c0a605d0cc825250286370a4.1511505932.git.arvind.yadav.cs@gmail.com>
On 11/24, Arvind Yadav wrote:
> pr_err() messages should end with a new-line to avoid other messages
> being concatenated.
>
> Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
> ---
Applied to clk-next
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH 5/6] clk: h8s2678: pr_err() strings should end with newlines
From: Stephen Boyd @ 2017-12-07 6:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1f71746f971b6969882e2d7827334b416178d898.1511505932.git.arvind.yadav.cs@gmail.com>
On 11/24, Arvind Yadav wrote:
> pr_err() messages should end with a new-line to avoid other messages
> being concatenated.
>
> Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
> ---
Applied to clk-next
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH 6/6] clk: h8300: pr_err() strings should end with newlines
From: Stephen Boyd @ 2017-12-07 6:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5fe05a034e646f03e6129c7782e38e37856f80a1.1511505932.git.arvind.yadav.cs@gmail.com>
On 11/24, Arvind Yadav wrote:
> pr_err() messages should end with a new-line to avoid other messages
> being concatenated.
>
> Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
> ---
Applied to clk-next
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH v2 0/3] Misc fixes up for MT7623 mmc
From: sean.wang at mediatek.com @ 2017-12-07 6:43 UTC (permalink / raw)
To: linux-arm-kernel
From: Sean Wang <sean.wang@mediatek.com>
Changes since v1:
- add tag from the feedback of v1
- enhance dt-binding documentation
Just add some fixes up for the current MT7623 support
Patch 1) complement the missing dt-bindings definitions
Patch 2) pick up the proper falling back as patch 1 defines.
Patch 3) SD-card detection issue caused by the wrong polarity is being fixed up
Sean Wang (3):
mmc: dt-bindings: add mmc support to MT7623 SoC
arm: dts: mt7623: update mmc related nodes with the appropriate
fallback
arm: dts: mt7623: fix card detection issue on bananapi-r2
Documentation/devicetree/bindings/mmc/mtk-sd.txt | 2 ++
arch/arm/boot/dts/mt7623.dtsi | 4 ++--
arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts | 2 +-
3 files changed, 5 insertions(+), 3 deletions(-)
--
2.7.4
^ permalink raw reply
* [PATCH v2 1/3] mmc: dt-bindings: add mmc support to MT7623 SoC
From: sean.wang at mediatek.com @ 2017-12-07 6:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1512628593.git.sean.wang@mediatek.com>
From: Sean Wang <sean.wang@mediatek.com>
Add the devicetree binding for MT7623 SoC using MT2701 as the fallback.
Cc: devicetree at vger.kernel.org
Signed-off-by: Sean Wang <sean.wang@mediatek.com>
Acked-by: Rob Herring <robh@kernel.org>
---
Documentation/devicetree/bindings/mmc/mtk-sd.txt | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/mmc/mtk-sd.txt b/Documentation/devicetree/bindings/mmc/mtk-sd.txt
index 72d2a73..9b80176 100644
--- a/Documentation/devicetree/bindings/mmc/mtk-sd.txt
+++ b/Documentation/devicetree/bindings/mmc/mtk-sd.txt
@@ -12,6 +12,8 @@ Required properties:
"mediatek,mt8173-mmc": for mmc host ip compatible with mt8173
"mediatek,mt2701-mmc": for mmc host ip compatible with mt2701
"mediatek,mt2712-mmc": for mmc host ip compatible with mt2712
+ "mediatek,mt7623-mmc", "mediatek,mt2701-mmc": for MT7623 SoC
+
- reg: physical base address of the controller and length
- interrupts: Should contain MSDC interrupt number
- clocks: Should contain phandle for the clock feeding the MMC controller
--
2.7.4
^ permalink raw reply related
* [PATCH v2 2/3] arm: dts: mt7623: update mmc related nodes with the appropriate fallback
From: sean.wang at mediatek.com @ 2017-12-07 6:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1512628593.git.sean.wang@mediatek.com>
From: Sean Wang <sean.wang@mediatek.com>
The current mmc related nodes should be falling back to MT2701
as the dt-binding defines and which has more appropriate setup
for MT7623.
Signed-off-by: Sean Wang <sean.wang@mediatek.com>
---
arch/arm/boot/dts/mt7623.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/mt7623.dtsi b/arch/arm/boot/dts/mt7623.dtsi
index 0640fb7..343d3b1 100644
--- a/arch/arm/boot/dts/mt7623.dtsi
+++ b/arch/arm/boot/dts/mt7623.dtsi
@@ -641,7 +641,7 @@
mmc0: mmc at 11230000 {
compatible = "mediatek,mt7623-mmc",
- "mediatek,mt8135-mmc";
+ "mediatek,mt2701-mmc";
reg = <0 0x11230000 0 0x1000>;
interrupts = <GIC_SPI 39 IRQ_TYPE_LEVEL_LOW>;
clocks = <&pericfg CLK_PERI_MSDC30_0>,
@@ -652,7 +652,7 @@
mmc1: mmc at 11240000 {
compatible = "mediatek,mt7623-mmc",
- "mediatek,mt8135-mmc";
+ "mediatek,mt2701-mmc";
reg = <0 0x11240000 0 0x1000>;
interrupts = <GIC_SPI 40 IRQ_TYPE_LEVEL_LOW>;
clocks = <&pericfg CLK_PERI_MSDC30_1>,
--
2.7.4
^ permalink raw reply related
* [PATCH v2 3/3] arm: dts: mt7623: fix card detection issue on bananapi-r2
From: sean.wang at mediatek.com @ 2017-12-07 6:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1512628593.git.sean.wang@mediatek.com>
From: Sean Wang <sean.wang@mediatek.com>
Fix that bananapi-r2 booting from SD-card would fail since incorrect
polarity is applied to the previous setup with GPIO_ACTIVE_HIGH.
Cc: stable at vger.kernel.org
Fixes: 0eed8d097612 ("arm: dts: mt7623: Add SD-card and EMMC to bananapi-r2")
Signed-off-by: Sean Wang <sean.wang@mediatek.com>
Tested-by: Matthias Brugger <matthias.bgg@gmail.com>
---
arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts b/arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts
index 688a863..7bf5aa2 100644
--- a/arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts
+++ b/arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts
@@ -204,7 +204,7 @@
bus-width = <4>;
max-frequency = <50000000>;
cap-sd-highspeed;
- cd-gpios = <&pio 261 0>;
+ cd-gpios = <&pio 261 GPIO_ACTIVE_LOW>;
vmmc-supply = <&mt6323_vmch_reg>;
vqmmc-supply = <&mt6323_vio18_reg>;
};
--
2.7.4
^ permalink raw reply related
* [PATCH V6 01/12] drivers: move clock common macros out from vendor directories
From: Stephen Boyd @ 2017-12-07 6:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171127100115.20655-2-chunyan.zhang@spreadtrum.com>
On 11/27, Chunyan Zhang wrote:
> These macros are used by more than one SoC vendor platforms, avoid to
> have many copies of these code, this patch moves them to the common
> clock directory which every clock drivers can access to.
>
> Signed-off-by: Chunyan Zhang <chunyan.zhang@spreadtrum.com>
> ---
> drivers/clk/clk_common.h | 60 ++++++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 60 insertions(+)
> create mode 100644 drivers/clk/clk_common.h
>
> diff --git a/drivers/clk/clk_common.h b/drivers/clk/clk_common.h
> new file mode 100644
> index 0000000..21e93d2
> --- /dev/null
> +++ b/drivers/clk/clk_common.h
> @@ -0,0 +1,60 @@
> +/*
> + * drivers/clk/clk_common.h
We don't need this in the file too. Please remove this line.
> + *
> + * SPDX-License-Identifier: GPL-2.0
> + */
> +
> +#ifndef _CLK_COMMON_H_
> +#define _CLK_COMMON_H_
> +
> +#include <linux/clk-provider.h>
Maybe these macros should just go into clk-provider.h?
> +
> +#define CLK_HW_INIT(_name, _parent, _ops, _flags) \
> + (&(struct clk_init_data) { \
> + .flags = _flags, \
> + .name = _name, \
> + .parent_names = (const char *[]) { _parent }, \
> + .num_parents = 1, \
> + .ops = _ops, \
> + })
Hopefully we don't extend the init structure anymore to have
something else. I guess we'll do something if that happens.
> +
> +#define CLK_HW_INIT_PARENTS(_name, _parents, _ops, _flags) \
> + (&(struct clk_init_data) { \
> + .flags = _flags, \
> + .name = _name, \
> + .parent_names = _parents, \
> + .num_parents = ARRAY_SIZE(_parents), \
> + .ops = _ops, \
> + })
> +
> +#define CLK_HW_INIT_NO_PARENT(_name, _ops, _flags) \
> + (&(struct clk_init_data) { \
> + .flags = _flags, \
> + .name = _name, \
> + .parent_names = NULL, \
> + .num_parents = 0, \
> + .ops = _ops, \
> + })
> +
> +#define CLK_FIXED_FACTOR(_struct, _name, _parent, \
> + _div, _mult, _flags) \
> + struct clk_fixed_factor _struct = { \
> + .div = _div, \
> + .mult = _mult, \
> + .hw.init = CLK_HW_INIT(_name, \
> + _parent, \
> + &clk_fixed_factor_ops, \
> + _flags), \
> + }
> +
> +#define CLK_FIXED_RATE(_struct, _name, _flags, \
> + _fixed_rate, _fixed_accuracy) \
> + struct clk_fixed_rate _struct = { \
> + .fixed_rate = _fixed_rate, \
> + .fixed_accuracy = _fixed_accuracy, \
> + .hw.init = CLK_HW_INIT_NO_PARENT(_name, \
> + &clk_fixed_rate_ops, \
> + _flags), \
> + }
Maybe don't add this one? Usually fixed rate clks come from DT.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH V6 02/12] clk: sprd: Add common infrastructure
From: Stephen Boyd @ 2017-12-07 6:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171127100115.20655-3-chunyan.zhang@spreadtrum.com>
On 11/27, Chunyan Zhang wrote:
> +
> + sprd_clk_set_regmap(desc, regmap);
> +
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(sprd_clk_regmap_init);
> +
> +int sprd_clk_probe(struct device *dev, struct clk_hw_onecell_data *clkhw)
> +{
> + int i, ret = 0;
ret shouldn't need to be initialized here.
> + struct clk_hw *hw;
> +
> + for (i = 0; i < clkhw->num; i++) {
> +
> + hw = clkhw->hws[i];
> +
> + if (!hw)
> + continue;
> +
> + ret = devm_clk_hw_register(dev, hw);
> + if (ret) {
> + dev_err(dev, "Couldn't register clock %d - %s\n",
> + i, hw->init->name);
> + return ret;
> + }
> + }
> +
> + ret = of_clk_add_hw_provider(dev->of_node, of_clk_hw_onecell_get,
> + clkhw);
You can use devm_ now for this.
> + if (ret)
> + dev_err(dev, "Failed to add clock provider.\n");
Please remove the full stop on error messages.
> +
> + return ret;
> +}
> +EXPORT_SYMBOL_GPL(sprd_clk_probe);
> +
> +MODULE_LICENSE("GPL v2");
> diff --git a/drivers/clk/sprd/common.h b/drivers/clk/sprd/common.h
> new file mode 100644
> index 0000000..8cd774e
> --- /dev/null
> +++ b/drivers/clk/sprd/common.h
> @@ -0,0 +1,52 @@
> +/*
> + * Spreadtrum clock infrastructure
> + *
> + * Copyright (C) 2017 Spreadtrum, Inc.
> + * Author: Chunyan Zhang <chunyan.zhang@spreadtrum.com>
> + *
> + * SPDX-License-Identifier: GPL-2.0
> + */
> +
> +#ifndef _SPRD_CLK_COMMON_H_
> +#define _SPRD_CLK_COMMON_H_
> +
> +#include <linux/clk-provider.h>
> +#include <linux/of_platform.h>
> +#include <linux/regmap.h>
> +
> +#include "../clk_common.h"
> +
> +struct device_node;
> +
> +struct sprd_clk_common {
> + struct regmap *regmap;
> + u32 reg;
> + struct clk_hw hw;
> +};
> +
> +struct sprd_clk_desc {
> + struct sprd_clk_common **clk_clks;
> + unsigned long num_clk_clks;
> + struct clk_hw_onecell_data *hw_clks;
> +};
> +
> +#define sprd_regmap_read(map, reg, val) \
> +({ \
> + (map) ? regmap_read((map), (reg), (val)) : (-EINVAL); \
Do we sometimes not have a map? This seems overly cautious.
> +})
> +
> +#define sprd_regmap_write(map, reg, val) \
> +({ \
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH] usb: xhci: fix TDS for MTK xHCI1.1
From: Mathias Nyman @ 2017-12-07 6:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <035626be9cb863b145b02369fe517d1c80335398.1512542108.git.chunfeng.yun@mediatek.com>
On 06.12.2017 08:42, Chunfeng Yun wrote:
> For MTK's xHCI 1.0 or latter, TD size is the number of max
> packet sized packets remaining in the TD, not including
> this TRB (following spec).
>
> For MTK's xHCI 0.96 and older, TD size is the number of max
> packet sized packets remaining in the TD, including this TRB
> (not following spec).
>
> Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
> ---
> drivers/usb/host/xhci-ring.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
> index c239c68..0619869 100644
> --- a/drivers/usb/host/xhci-ring.c
> +++ b/drivers/usb/host/xhci-ring.c
> @@ -3108,7 +3108,7 @@ static u32 xhci_td_remainder(struct xhci_hcd *xhci, int transferred,
> {
> u32 maxp, total_packet_count;
>
> - /* MTK xHCI is mostly 0.97 but contains some features from 1.0 */
> + /* MTK xHCI 0.96 contains some features from 1.0 */
> if (xhci->hci_version < 0x100 && !(xhci->quirks & XHCI_MTK_HOST))
> return ((td_total_len - transferred) >> 10);
>
> @@ -3117,8 +3117,8 @@ static u32 xhci_td_remainder(struct xhci_hcd *xhci, int transferred,
> trb_buff_len == td_total_len)
> return 0;
>
> - /* for MTK xHCI, TD size doesn't include this TRB */
> - if (xhci->quirks & XHCI_MTK_HOST)
> + /* for MTK xHCI 0.96, TD size include this TRB, but not in 1.x */
> + if ((xhci->quirks & XHCI_MTK_HOST) && (xhci->hci_version < 0x100))
> trb_buff_len = 0;
>
> maxp = usb_endpoint_maxp(&urb->ep->desc);
>
Thanks, adding.
Adding stable tag as well
-Mathias
^ permalink raw reply
* ARM64: Need to ignore exception in bad_mode()
From: Hari Vyas @ 2017-12-07 6:59 UTC (permalink / raw)
To: linux-arm-kernel
(Re-sending mail in plain text format)
Hi Will , Catalin,
One of our Broadcom SoC "Stingray" is based on ARM64 architecture.
In pcie hot-plug-out scenario where EP card is surprisingly plugged-out,
few ongoing memory transaction times out and our pcie IDM wrapper
eventually results in an exception which is expected one in
this case.
If we don't ignore exception in this case, kernel crashes.
We are planning to ignore "expected exception" by changing entry.S
and traps.c. Please check and provide us your opinion regarding below
approach. I have highlighted important changes of
arch/arm64/kernel/entry.S and arch/arm64/kernel/traps.c
hariv at vijay-Precision-WorkStation-T3400:~/BCM_MASTER/kernel$ git diff
arch/arm64/kernel/entry.S
diff --git a/arch/arm64/kernel/entry.S b/arch/arm64/kernel/entry.S
index e1c59d4..54b5eb2 100644
--- a/arch/arm64/kernel/entry.S
+++ b/arch/arm64/kernel/entry.S
@@ -430,6 +430,9 @@ __bad_stack:
mov x1, #\reason
mrs x2, esr_el1
bl bad_mode
+ cbnz x0, 2f
+ kernel_exit el
+2:
ASM_BUG()
.endm
hariv at vijay-Precision-WorkStation-T3400:~/BCM_MASTER/kernel$ git diff
arch/arm64/kernel/traps.c
diff --git a/arch/arm64/kernel/traps.c b/arch/arm64/kernel/traps.c
index 8383af1..709f399 100644
--- a/arch/arm64/kernel/traps.c
+++ b/arch/arm64/kernel/traps.c
@@ -48,6 +48,8 @@
#include <asm/exception.h>
#include <asm/system_misc.h>
#include <asm/sysreg.h>
int show_unhandled_signals = 1;
+struct exception_list {
+ struct list_head head;
+ long unsigned data;
+ int (*cb)(long unsigned data);
+};
+struct list_head exception_head = LIST_HEAD_INIT(exception_head);
+
+int register_exception(int (*cb)(long unsigned data), long unsigned data)
+{
+ struct exception_list *entry;
+
+ entry=kmalloc(sizeof(struct exception_list *),GFP_KERNEL);
+ entry->data = data;
+ entry->cb = cb;
+ list_add(&entry->head,&exception_head);
+ return 0;
+}
+EXPORT_SYMBOL(register_exception);
+
/*
* Dump out the contents of some kernel memory nicely...
*/
+
static void dump_mem(const char *lvl, const char *str, unsigned long
bottom,
unsigned long top)
{
@@ -633,10 +655,22 @@ const char *esr_get_class_string(u32 esr)
* bad_mode handles the impossible case in the exception vector. This is
always
* fatal.
*/
-asmlinkage void bad_mode(struct pt_regs *regs, int reason, unsigned int
esr)
+asmlinkage int bad_mode(struct pt_regs *regs, int reason, unsigned int
esr)
{
+ struct exception_list *entry;
+ struct list_head *ptr;
+ int ret;
+
console_verbose();
+ list_for_each(ptr,&exception_head) {
+ entry=list_entry(ptr,struct exception_list,head);
+ ret = entry->cb(entry->data);
+ if (ret == NOTIFY_STOP) {
+ pr_crit("Expected exception so ignoring\n");
+ return 0;
+ }
+ }
pr_crit("Bad mode in %s handler detected on CPU%d, code 0x%08x --
%s\n",
handler[reason], smp_processor_id(), esr,
esr_get_class_string(esr));
@@ -644,6 +678,7 @@ asmlinkage void bad_mode(struct pt_regs *regs, int
reason, u
die("Oops - bad mode", regs, 0);
local_irq_disable();
panic("bad mode");
+ return 1; /* Must not reach */
}
/*
hariv at vijay-Precision-WorkStation-T3400:~/BCM_MASTER/kernel$
Regards,
hari
^ permalink raw reply related
* [PATCH v3 1/3] dt-bindings: clk: Hi3660: Document stub clock
From: Stephen Boyd @ 2017-12-07 7:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1510910852-2175-2-git-send-email-xuyiping@hisilicon.com>
On 11/17, Xu YiPing wrote:
> From: Leo Yan <leo.yan@linaro.org>
>
> Document the DT binding for stub clock which is used for CPU,
> GPU and DDR frequency scaling.
>
> Acked-by: Rob Herring <robh@kernel.org>
> Signed-off-by: Leo Yan <leo.yan@linaro.org>
> ---
Applied to clk-next
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH 2/2] arm64: allwinner: a64: bananapi-m64: add usb otg
From: Chen-Yu Tsai @ 2017-12-07 7:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAD6G_RR-L1RH899peZgWdapyrENJC7b9-H0pNPu9+Ji93JnQ=w@mail.gmail.com>
On Thu, Dec 7, 2017 at 2:54 PM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
> On Thu, Dec 7, 2017 at 11:56 AM, Chen-Yu Tsai <wens@csie.org> wrote:
>> On Thu, Dec 7, 2017 at 2:18 PM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
>>> On Thu, Dec 7, 2017 at 8:54 AM, Chen-Yu Tsai <wens@csie.org> wrote:
>>>> On Thu, Dec 7, 2017 at 1:51 AM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
>>>>> usb otg on bananapi-m64 has configured with USB-ID with PH9
>>>>> and USB-DRVVBUS attached with dcdc1 regulatort.
>>>>
>>>> That is not how you read the schematic...
>>>>
>>>> Intersecting lines that are tied together will have a dot representing
>>>> the connection. The DCDC1 line is a pull-up for the ID pin. This is very
>>>> clear because it has a resistor connected in series.
>>>>
>>>> VBUS for OTG is controlled by the IC displayed to the right in the
>>>> schematic, which is powered from 5V, and controlled by the DRVVBUS
>>>> pin from the PMIC. Please take a look at how the A31/A33/A83T board
>>>> dts files represent this.
>>>
>>> This is where I confused, USB-DRVVBUS is connected to pin 51 of PMIC
>>> if we add 5v regulator how can configure gpio number for this? I saw
>>
>> From the axp20x bindings:
>>
>> - x-powers,drive-vbus-en: boolean, set this when the N_VBUSEN pin is
>> used as an output pin to control an external
>> regulator to drive the OTG VBus, rather then
>> as an input pin which signals whether the
>> board is driving OTG VBus or not.
>> (axp221 / axp223 / axp813 only)
>>
>> Setting this allows you to use the "drivevbus" regulator under the PMIC.
>> As I said, look at how other boards are doing it.
>>
>>> sun8i-a33-olinuxino.dts which is also similar but it has gpio = <&pio
>>> 1 9 GPIO_ACTIVE_HIGH>;
>>
>> I have no idea where you saw this. It does not exist in my tree.
>>
>> Why don't you just trace backwards from the usb0_vbus-supply property
>> under the usbphy node, and see where it all leads.
>
> This what exactly I did, usb0_vbus-supply = <®_drivevbus>; on
This is not what you did in your patch.
> sun8i-a33-olinuxino.dts is using usb0-vbus from
> sunxi-common-regulators.dtsi. reg_usb0_vbus regulator using gpio9
> which I couldn't find it on schematics.
And I'm telling you that in mainline a33-olinuxino.dts it is:
usb0_vbus-supply = <®_drivevbus>;
It has been that way since the initial commit adding the file.
What tree are you looking at exactly? Take a good look at everything,
including your patch, and stop arguing.
ChenYu
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox