* [PATCH v3 2/3] powerpc/reloc64: add support for 32-bit CRC pseudo-symbols
From: Ard Biesheuvel @ 2016-11-25 12:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87oa13ssqq.fsf@concordia.ellerman.id.au>
On 25 November 2016 at 11:29, Michael Ellerman <mpe@ellerman.id.au> wrote:
> Ard Biesheuvel <ard.biesheuvel@linaro.org> writes:
>
>> diff --git a/arch/powerpc/relocs_check.sh b/arch/powerpc/relocs_check.sh
>> index ec2d5c835170..2f510fbc87da 100755
>> --- a/arch/powerpc/relocs_check.sh
>> +++ b/arch/powerpc/relocs_check.sh
>> @@ -43,7 +43,8 @@ R_PPC_ADDR16_HA
>> R_PPC_RELATIVE
>> R_PPC_NONE' |
>> grep -E -v '\<R_PPC64_ADDR64[[:space:]]+mach_' |
>> - grep -E -v '\<R_PPC64_ADDR64[[:space:]]+__crc_'
>> + grep -E -v '\<R_PPC64_ADDR64[[:space:]]+__crc_' |
>> + grep -E -v '\<R_PPC64_ADDR32[[:space:]]+\*ABS\*'
>
> I'm still getting:
>
> WARNING: 24 bad relocations
> c000000000d307c4 R_PPC64_ADDR32 __crc___arch_hweight16
> c000000000d307c8 R_PPC64_ADDR32 __crc___arch_hweight32
> c000000000d307cc R_PPC64_ADDR32 __crc___arch_hweight64
> c000000000d307d0 R_PPC64_ADDR32 __crc___arch_hweight8
> c000000000d30848 R_PPC64_ADDR32 __crc___bswapdi2
> c000000000d30854 R_PPC64_ADDR32 __crc___clear_user
> c000000000d30868 R_PPC64_ADDR32 __crc___copy_tofrom_user
> c000000000d30d4c R_PPC64_ADDR32 __crc__mcount
> c000000000d31344 R_PPC64_ADDR32 __crc_copy_page
> c000000000d3141c R_PPC64_ADDR32 __crc_current_stack_pointer
> c000000000d31840 R_PPC64_ADDR32 __crc_empty_zero_page
> c000000000d31a7c R_PPC64_ADDR32 __crc_flush_dcache_range
> c000000000d31a84 R_PPC64_ADDR32 __crc_flush_icache_range
> c000000000d32608 R_PPC64_ADDR32 __crc_load_fp_state
> c000000000d32614 R_PPC64_ADDR32 __crc_load_vr_state
> c000000000d32828 R_PPC64_ADDR32 __crc_memchr
> c000000000d32830 R_PPC64_ADDR32 __crc_memcmp
> c000000000d32834 R_PPC64_ADDR32 __crc_memcpy
> c000000000d32840 R_PPC64_ADDR32 __crc_memmove
> c000000000d32888 R_PPC64_ADDR32 __crc_memset
> c000000000d33c9c R_PPC64_ADDR32 __crc_store_fp_state
> c000000000d33ca0 R_PPC64_ADDR32 __crc_store_vr_state
> c000000000d33cf0 R_PPC64_ADDR32 __crc_strncmp
> c000000000d33cf4 R_PPC64_ADDR32 __crc_strncpy
>
Ah right, my bad. The regex above should switch to ADDR32 as well for
__crc_ symbols.
>
> If I just add those to the whitelist it builds, but then things aren't
> happy at boot:
>
>
> [ 7.607687] kvm: disagrees about version of symbol module_layout
> [ 7.846799] virtio: disagrees about version of symbol module_layout
> [ 22.012615] crc32c_vpmsum: disagrees about version of symbol module_layout
> [ 22.012959] libcrc32c: disagrees about version of symbol module_layout
>
Sigh. I suppose your modversions fixes are queued for v4.10? It's
probably best to revisit this after the v4.10 merge window closes
then, just to make sure I'm not aiming for a moving target.
Thanks,
Ard.
^ permalink raw reply
* Tearing down DMA transfer setup after DMA client has finished
From: Mason @ 2016-11-25 12:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161125045549.GC2698@localhost>
On 25/11/2016 05:55, Vinod Koul wrote:
> On Wed, Nov 23, 2016 at 11:25:44AM +0100, Mason wrote:
>
>> On my platform, setting up a DMA transfer is a two-step process:
>>
>> 1) configure the "switch box" to connect a device to a memory channel
>> 2) configure the transfer details (address, size, command)
>>
>> When the transfer is done, the sbox setup can be torn down,
>> and the DMA driver can start another transfer.
>>
>> The current software architecture for my NFC (NAND Flash controller)
>> driver is as follows (for one DMA transfer).
>>
>> sg_init_one
>> dma_map_sg
>> dmaengine_prep_slave_sg
>> dmaengine_submit
>> dma_async_issue_pending
>> configure_NFC_transfer
>> wait_for_IRQ_from_DMA_engine // via DMA_PREP_INTERRUPT
>> wait_for_NFC_idle
>> dma_unmap_sg
>
> Looking at thread and discussion now, first thinking would be to ensure
> the transaction is completed properly and then isr fired. You may need
> to talk to your HW designers to find a way for that. It is quite common
> that DMA controllers will fire and complete whereas the transaction is
> still in flight.
It seems there is a disconnect between what Linux expects - an IRQ
when the transfer is complete - and the quirks of this HW :-(
On this system, there are MBUS "agents" connected via a "switch box".
An agent fires an IRQ when it has dealt with its *half* of the transfer.
SOURCE_AGENT <---> SBOX <---> DESTINATION_AGENT
Here are the steps for a transfer, in the general case:
1) setup the sbox to connect SOURCE TO DEST
2) configure source to send N bytes
3) configure dest to receive N bytes
When SOURCE_AGENT has sent N bytes, it fires an IRQ
When DEST_AGENT has received N bytes, it fires an IRQ
The sbox connection can be torn down only when the destination
agent has received all bytes.
(And the twist is that some agents do not have an IRQ line.)
The system provides 3 RAM-to-sbox agents (read channels)
and 3 sbox-to-RAM agents (write channels).
The NAND Flash controller read and write agents do not have
IRQ lines.
So for a NAND-to-memory transfer (read from device)
- nothing happens when the NFC has finished sending N bytes to the sbox
- the write channel fires an IRQ when it has received N bytes
In that case, one IRQ fires when the transfer is complete,
like Linux expects.
For a memory-to-NAND transfer (write to device)
- the read channel fires an IRQ when it has sent N bytes
- the NFC driver is supposed to poll the NFC to determine
when the controller has finished writing N bytes
In that case, the IRQ does not indicate that the transfer
is complete, merely that the sending half has finished
its part.
For a memory-to-memory transfer (memcpy)
- the read channel fires an IRQ when it has sent N bytes
- the write channel fires an IRQ when it has received N bytes
So you actually get two IRQs in that case, which I don't
think Linux (or the current DMA driver) expects.
I'm not sure how we're supposed to handle this kind of HW
in Linux? (That's why I started this thread.)
> If that is not doable, then since you claim this is custom part which
> other vendors won't use (hope we are wrong down the line),
I'm not sure how to interpret "you claim this is custom part".
Do you mean I may be wrong, that it is not custom?
I don't know if other vendors may have HW with the same
quirky behavior. What do you mean about being wrong down
the line?
> then we can have a custom api,
>
> foo_sbox_configure(bool enable, ...);
>
> This can be invoked from NFC driver when required for configuration and
> teardown. For very specific cases where people need some specific
> configuration we do allow custom APIs.
I don't think that would work. The fundamental issue is
that Linux expects a single IRQ to indicate "transfer
complete". And the driver (as written) starts a new
transfer as soon as the IRQ fires.
But the HW may generate 0, 1, or even 2 IRQs for a single
transfer. And when there is a single IRQ, it may not
indicate "transfer complete" (as seen above).
> Only problem with that would be it wont be a generic solution
> and you seem to be fine with that.
I think it is possible to have a generic solution:
Right now, the callback is called from tasklet context.
If we can have a new flag to have the callback invoked
directly from the ISR, then the driver for the client
device can do what is required.
For example, the NFC driver waits for the IRQ from the
memory agent, and then polls the controller itself.
I can whip up a proof-of-concept if it's better to
illustrate with a patch?
Regards.
^ permalink raw reply
* Tearing down DMA transfer setup after DMA client has finished
From: Russell King - ARM Linux @ 2016-11-25 12:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161125045549.GC2698@localhost>
On Fri, Nov 25, 2016 at 10:25:49AM +0530, Vinod Koul wrote:
> Looking at thread and discussion now, first thinking would be to ensure
> the transaction is completed properly and then isr fired. You may need
> to talk to your HW designers to find a way for that. It is quite common
> that DMA controllers will fire and complete whereas the transaction is
> still in flight.
>
> If that is not doable, then since you claim this is custom part which
> other vendors wont use (hope we are wrong down the line), then we can
> have a custom api,
>
> foo_sbox_configure(bool enable, ...);
>
> This can be invoked from NFC driver when required for configuration and
> teardown. For very specific cases where people need some specific
> configuration we do allow custom APIs.
>
> Only problem with that would be it wont be a generic solution and you
> seem to be fine with that.
Isn't this just the same problem as PL08x or any other system which
has multiple requests from devices, but only a limited number of
hardware channels - so you have to route the request signals to the
appropriate hardware channels according to the requests queued up?
If so, no new "custom" APIs are required, it's already able to be
solved within the DMA engine drivers...
(We also have more complex situations already supported, such as
PL08x with a FPGA routing on three of its request signals.)
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* [PATCH 5/7] efi: Get the secure boot status [ver #3]
From: Ard Biesheuvel @ 2016-11-25 12:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <17565.1480077303@warthog.procyon.org.uk>
On 25 November 2016 at 12:35, David Howells <dhowells@redhat.com> wrote:
> Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
>
>> Yes. In pre-2.6, DeployedMode is not a reserved name, and so it may be
>> possible for someone to slip in a DeployedMode=0 on a secure boot
>> enabled system to trick the kernel into thinking lockdown should be
>> disabled.
>
> How does one get the version number? Unfortunately, searching the document
> for 'version' doesn't help as every page has that in the footer:-/
>
There is a 'revision' field in the header ('hdr') of the EFI system
table, so something like
(sys_table_arg->hdr.revision >> 16) > 2 ||
((sys_table_arg->hdr.revision >> 16) == 2 &&
(sys_table_arg->hdr.revision & 0xffff) >= 6)
should do the trick I think
>> > + if (val == 1)
>> > + return 0;
>>
>> I think the logic is the wrong way around here. Secure Boot is enabled
>> if SecureBoot=1 and SetupMode=0, unless DeployedMode=0. So you should
>> return 0 here if val == 0, but only when running on 2.6 or later.
>
> Good point.
>
> David
^ permalink raw reply
* [PATCH 5/7] efi: Get the secure boot status [ver #3]
From: David Howells @ 2016-11-25 12:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKv+Gu_d5+Kvo7Tptnpg7kfjpqxhQ3a3nsQ0Ufsm6rBOFry+mQ@mail.gmail.com>
Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
> Yes. In pre-2.6, DeployedMode is not a reserved name, and so it may be
> possible for someone to slip in a DeployedMode=0 on a secure boot
> enabled system to trick the kernel into thinking lockdown should be
> disabled.
How does one get the version number? Unfortunately, searching the document
for 'version' doesn't help as every page has that in the footer:-/
> > + if (val == 1)
> > + return 0;
>
> I think the logic is the wrong way around here. Secure Boot is enabled
> if SecureBoot=1 and SetupMode=0, unless DeployedMode=0. So you should
> return 0 here if val == 0, but only when running on 2.6 or later.
Good point.
David
^ permalink raw reply
* [PATCH v2 8/8] ARM: dts: sun8i-h3: orange-pi-pc: Enable audio codec
From: Chen-Yu Tsai @ 2016-11-25 12:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161125123442.28410-1-wens@csie.org>
The Orange Pi PC routes the LINEOUT pins to the audio out jack on the
board. The onboard microphone is routed to MIC1, with MBIAS providing
power.
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
---
arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts b/arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts
index 98b85be61e17..d43978d3294e 100644
--- a/arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts
+++ b/arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts
@@ -90,6 +90,14 @@
};
};
+&codec {
+ allwinner,audio-routing =
+ "Line Out", "LINEOUT",
+ "MIC1", "Mic",
+ "Mic", "MBIAS";
+ status = "okay";
+};
+
&ehci1 {
status = "okay";
};
--
2.10.2
^ permalink raw reply related
* [PATCH v2 7/8] ARM: dts: sun8i-h3: Add device nodes for audio codec and its analog controls
From: Chen-Yu Tsai @ 2016-11-25 12:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161125123442.28410-1-wens@csie.org>
Now that we support the audio codec found on the Allwinner H3 SoC, add
device nodes for it.
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
---
arch/arm/boot/dts/sun8i-h3.dtsi | 19 +++++++++++++++++++
1 file changed, 19 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi b/arch/arm/boot/dts/sun8i-h3.dtsi
index fca66bf2dec5..496efc564bbe 100644
--- a/arch/arm/boot/dts/sun8i-h3.dtsi
+++ b/arch/arm/boot/dts/sun8i-h3.dtsi
@@ -465,6 +465,20 @@
status = "disabled";
};
+ codec: codec at 01c22c00 {
+ #sound-dai-cells = <0>;
+ compatible = "allwinner,sun8i-h3-codec";
+ reg = <0x01c22c00 0x400>;
+ interrupts = <GIC_SPI 29 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&ccu CLK_BUS_CODEC>, <&ccu CLK_AC_DIG>;
+ clock-names = "apb", "codec";
+ resets = <&ccu RST_BUS_CODEC>;
+ dmas = <&dma 15>, <&dma 15>;
+ dma-names = "rx", "tx";
+ allwinner,codec-analog-controls = <&codec_analog>;
+ status = "disabled";
+ };
+
uart0: serial at 01c28000 {
compatible = "snps,dw-apb-uart";
reg = <0x01c28000 0x400>;
@@ -580,6 +594,11 @@
#reset-cells = <1>;
};
+ codec_analog: codec-analog at 01f015c0 {
+ compatible = "allwinner,sun8i-h3-codec-analog";
+ reg = <0x01f015c0 0x4>;
+ };
+
ir: ir at 01f02000 {
compatible = "allwinner,sun5i-a13-ir";
clocks = <&apb0_gates 1>, <&ir_clk>;
--
2.10.2
^ permalink raw reply related
* [PATCH v2 6/8] ASoC: sun4i-codec: Add support for H3 codec
From: Chen-Yu Tsai @ 2016-11-25 12:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161125123442.28410-1-wens@csie.org>
The codec on the H3 is similar to the one found on the A31. One key
difference is the analog path controls are routed through the PRCM
block. This is supported by the sun8i-codec-analog driver, and tied
into this codec driver with the audio card's aux_dev.
In addition, the H3 has no HP (headphone) and HBIAS support, and no
MIC3 input. The FIFO related registers are slightly rearranged.
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Acked-by: Rob Herring <robh@kernel.org>
---
.../devicetree/bindings/sound/sun4i-codec.txt | 3 +
sound/soc/sunxi/sun4i-codec.c | 71 ++++++++++++++++++++++
2 files changed, 74 insertions(+)
diff --git a/Documentation/devicetree/bindings/sound/sun4i-codec.txt b/Documentation/devicetree/bindings/sound/sun4i-codec.txt
index f7a548b604fc..3033bd8aab0f 100644
--- a/Documentation/devicetree/bindings/sound/sun4i-codec.txt
+++ b/Documentation/devicetree/bindings/sound/sun4i-codec.txt
@@ -6,6 +6,7 @@ Required properties:
- "allwinner,sun6i-a31-codec"
- "allwinner,sun7i-a20-codec"
- "allwinner,sun8i-a23-codec"
+ - "allwinner,sun8i-h3-codec"
- reg: must contain the registers location and length
- interrupts: must contain the codec interrupt
- dmas: DMA channels for tx and rx dma. See the DMA client binding,
@@ -23,6 +24,7 @@ Optional properties:
Required properties for the following compatibles:
- "allwinner,sun6i-a31-codec"
- "allwinner,sun8i-a23-codec"
+ - "allwinner,sun8i-h3-codec"
- resets: phandle to the reset control for this device
- allwinner,audio-routing: A list of the connections between audio components.
Each entry is a pair of strings, the first being the
@@ -52,6 +54,7 @@ Required properties for the following compatibles:
Required properties for the following compatibles:
- "allwinner,sun8i-a23-codec"
+ - "allwinner,sun8i-h3-codec"
- allwinner,codec-analog-controls: A phandle to the codec analog controls
block in the PRCM.
diff --git a/sound/soc/sunxi/sun4i-codec.c b/sound/soc/sunxi/sun4i-codec.c
index ada5fa055950..848af01692a0 100644
--- a/sound/soc/sunxi/sun4i-codec.c
+++ b/sound/soc/sunxi/sun4i-codec.c
@@ -217,6 +217,13 @@
#define SUN8I_A23_CODEC_DAC_TXCNT (0x1c)
#define SUN8I_A23_CODEC_ADC_RXCNT (0x20)
+/* TX FIFO moved on H3 */
+#define SUN8I_H3_CODEC_DAC_TXDATA (0x20)
+#define SUN8I_H3_CODEC_DAC_DBG (0x48)
+#define SUN8I_H3_CODEC_ADC_DBG (0x4c)
+
+/* TODO H3 DAP (Digital Audio Processing) bits */
+
struct sun4i_codec {
struct device *dev;
struct regmap *regmap;
@@ -1293,6 +1300,44 @@ static struct snd_soc_card *sun8i_a23_codec_create_card(struct device *dev)
return card;
};
+static struct snd_soc_card *sun8i_h3_codec_create_card(struct device *dev)
+{
+ struct snd_soc_card *card;
+ int ret;
+
+ card = devm_kzalloc(dev, sizeof(*card), GFP_KERNEL);
+ if (!card)
+ return ERR_PTR(-ENOMEM);
+
+ aux_dev.codec_of_node = of_parse_phandle(dev->of_node,
+ "allwinner,codec-analog-controls",
+ 0);
+ if (!aux_dev.codec_of_node) {
+ dev_err(dev, "Can't find analog controls for codec.\n");
+ return ERR_PTR(-EINVAL);
+ };
+
+ card->dai_link = sun4i_codec_create_link(dev, &card->num_links);
+ if (!card->dai_link)
+ return ERR_PTR(-ENOMEM);
+
+ card->dev = dev;
+ card->name = "H3 Audio Codec";
+ card->dapm_widgets = sun6i_codec_card_dapm_widgets;
+ card->num_dapm_widgets = ARRAY_SIZE(sun6i_codec_card_dapm_widgets);
+ card->dapm_routes = sun8i_codec_card_routes;
+ card->num_dapm_routes = ARRAY_SIZE(sun8i_codec_card_routes);
+ card->aux_dev = &aux_dev;
+ card->num_aux_devs = 1;
+ card->fully_routed = true;
+
+ ret = snd_soc_of_parse_audio_routing(card, "allwinner,audio-routing");
+ if (ret)
+ dev_warn(dev, "failed to parse audio-routing: %d\n", ret);
+
+ return card;
+};
+
static const struct regmap_config sun4i_codec_regmap_config = {
.reg_bits = 32,
.reg_stride = 4,
@@ -1321,6 +1366,13 @@ static const struct regmap_config sun8i_a23_codec_regmap_config = {
.max_register = SUN8I_A23_CODEC_ADC_RXCNT,
};
+static const struct regmap_config sun8i_h3_codec_regmap_config = {
+ .reg_bits = 32,
+ .reg_stride = 4,
+ .val_bits = 32,
+ .max_register = SUN8I_H3_CODEC_ADC_DBG,
+};
+
struct sun4i_codec_quirks {
const struct regmap_config *regmap_config;
const struct snd_soc_codec_driver *codec;
@@ -1369,6 +1421,21 @@ static const struct sun4i_codec_quirks sun8i_a23_codec_quirks = {
.has_reset = true,
};
+static const struct sun4i_codec_quirks sun8i_h3_codec_quirks = {
+ .regmap_config = &sun8i_h3_codec_regmap_config,
+ /*
+ * TODO Share the codec structure with A23 for now.
+ * This should be split out when adding digital audio
+ * processing support for the H3.
+ */
+ .codec = &sun8i_a23_codec_codec,
+ .create_card = sun8i_h3_codec_create_card,
+ .reg_adc_fifoc = REG_FIELD(SUN6I_CODEC_ADC_FIFOC, 0, 31),
+ .reg_dac_txdata = SUN8I_H3_CODEC_DAC_TXDATA,
+ .reg_adc_rxdata = SUN6I_CODEC_ADC_RXDATA,
+ .has_reset = true,
+};
+
static const struct of_device_id sun4i_codec_of_match[] = {
{
.compatible = "allwinner,sun4i-a10-codec",
@@ -1386,6 +1453,10 @@ static const struct of_device_id sun4i_codec_of_match[] = {
.compatible = "allwinner,sun8i-a23-codec",
.data = &sun8i_a23_codec_quirks,
},
+ {
+ .compatible = "allwinner,sun8i-h3-codec",
+ .data = &sun8i_h3_codec_quirks,
+ },
{}
};
MODULE_DEVICE_TABLE(of, sun4i_codec_of_match);
--
2.10.2
^ permalink raw reply related
* [PATCH v2 5/8] ARM: dts: sun8i-a23: q8-tablet: Enable internal audio codec
From: Chen-Yu Tsai @ 2016-11-25 12:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161125123442.28410-1-wens@csie.org>
The A23 Q8 tablets have an internal mono speaker w/ external amp
which has a shutdown control tied to a GPIO pin. Both the speaker
amp and the headphone jack are tied to the HP output pins. While
the speaker is mono, the headset jack is stereo. Unfortunately
the driver does not support automatic switching of this.
In addition, the headset is DC coupled, or "direct drive" enabled.
The headset's microphone is tied to MIC2 with HBIAS providing power.
A separate internal microphone is tied to MIC1 with MBIAS providing
power.
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
---
arch/arm/boot/dts/sun8i-a23-q8-tablet.dts | 23 +++++++++++++++++++++++
1 file changed, 23 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-a23-q8-tablet.dts b/arch/arm/boot/dts/sun8i-a23-q8-tablet.dts
index 956320a6cc78..3ab5c0c09d93 100644
--- a/arch/arm/boot/dts/sun8i-a23-q8-tablet.dts
+++ b/arch/arm/boot/dts/sun8i-a23-q8-tablet.dts
@@ -48,3 +48,26 @@
model = "Q8 A23 Tablet";
compatible = "allwinner,q8-a23", "allwinner,sun8i-a23";
};
+
+&codec {
+ pinctrl-0 = <&codec_pa_pin>;
+ allwinner,pa-gpios = <&pio 7 9 GPIO_ACTIVE_HIGH>; /* PH9 */
+ allwinner,audio-routing =
+ "Headphone", "HP",
+ "Headphone", "HPCOM",
+ "Speaker", "HP",
+ "MIC1", "Mic",
+ "MIC2", "Headset Mic",
+ "Mic", "MBIAS",
+ "Headset Mic", "HBIAS";
+ status = "okay";
+};
+
+&pio {
+ codec_pa_pin: codec_pa_pin at 0 {
+ allwinner,pins = "PH9";
+ allwinner,function = "gpio_out";
+ allwinner,drive = <SUN4I_PINCTRL_10_MA>;
+ allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
+ };
+};
--
2.10.2
^ permalink raw reply related
* [PATCH v2 4/8] ARM: dts: sun8i-a23: Add device node for internal audio codec
From: Chen-Yu Tsai @ 2016-11-25 12:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161125123442.28410-1-wens@csie.org>
Now that we have a device tree binding and driver for the A23's
internal audio codec, add a device node for it.
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
---
arch/arm/boot/dts/sun8i-a23.dtsi | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-a23.dtsi b/arch/arm/boot/dts/sun8i-a23.dtsi
index 54d045dab825..4d1f929780a8 100644
--- a/arch/arm/boot/dts/sun8i-a23.dtsi
+++ b/arch/arm/boot/dts/sun8i-a23.dtsi
@@ -48,6 +48,22 @@
memory {
reg = <0x40000000 0x40000000>;
};
+
+ soc at 01c00000 {
+ codec: codec at 01c22c00 {
+ #sound-dai-cells = <0>;
+ compatible = "allwinner,sun8i-a23-codec";
+ reg = <0x01c22c00 0x400>;
+ interrupts = <GIC_SPI 29 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&ccu CLK_BUS_CODEC>, <&ccu CLK_AC_DIG>;
+ clock-names = "apb", "codec";
+ resets = <&ccu RST_BUS_CODEC>;
+ dmas = <&dma 15>, <&dma 15>;
+ dma-names = "rx", "tx";
+ allwinner,codec-analog-controls = <&codec_analog>;
+ status = "disabled";
+ };
+ };
};
&ccu {
--
2.10.2
^ permalink raw reply related
* [PATCH v2 3/8] ARM: dts: sun8i: Add codec analog path controls node in PRCM for A23/A33
From: Chen-Yu Tsai @ 2016-11-25 12:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161125123442.28410-1-wens@csie.org>
On the A23/A33, the internal codec's analog path controls are located in
the PRCM node.
Add a sub-device node to the PRCM for it.
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
---
arch/arm/boot/dts/sun8i-a23-a33.dtsi | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-a23-a33.dtsi b/arch/arm/boot/dts/sun8i-a23-a33.dtsi
index bc3e936edfcf..d9c6f16f95f1 100644
--- a/arch/arm/boot/dts/sun8i-a23-a33.dtsi
+++ b/arch/arm/boot/dts/sun8i-a23-a33.dtsi
@@ -538,6 +538,10 @@
compatible = "allwinner,sun6i-a31-clock-reset";
#reset-cells = <1>;
};
+
+ codec_analog: codec-analog {
+ compatible = "allwinner,sun8i-a23-codec-analog";
+ };
};
cpucfg at 01f01c00 {
--
2.10.2
^ permalink raw reply related
* [PATCH v2 2/8] ASoC: sun4i-codec: Add support for A23 codec
From: Chen-Yu Tsai @ 2016-11-25 12:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161125123442.28410-1-wens@csie.org>
The codec in the A23 is similar to the one found on the A31. One key
difference is the analog path controls are routed through the PRCM
block. This is supported by the sun8i-codec-analog driver, and tied
into this codec driver with the audio card's aux_dev.
In addition, the A23 does not have LINEOUT, and it does not support
headset jack detection or buttons.
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Acked-by: Rob Herring <robh@kernel.org>
---
.../devicetree/bindings/sound/sun4i-codec.txt | 11 ++-
sound/soc/sunxi/sun4i-codec.c | 108 +++++++++++++++++++++
2 files changed, 117 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/sound/sun4i-codec.txt b/Documentation/devicetree/bindings/sound/sun4i-codec.txt
index d91a95377f49..f7a548b604fc 100644
--- a/Documentation/devicetree/bindings/sound/sun4i-codec.txt
+++ b/Documentation/devicetree/bindings/sound/sun4i-codec.txt
@@ -5,6 +5,7 @@ Required properties:
- "allwinner,sun4i-a10-codec"
- "allwinner,sun6i-a31-codec"
- "allwinner,sun7i-a20-codec"
+ - "allwinner,sun8i-a23-codec"
- reg: must contain the registers location and length
- interrupts: must contain the codec interrupt
- dmas: DMA channels for tx and rx dma. See the DMA client binding,
@@ -21,6 +22,7 @@ Optional properties:
Required properties for the following compatibles:
- "allwinner,sun6i-a31-codec"
+ - "allwinner,sun8i-a23-codec"
- resets: phandle to the reset control for this device
- allwinner,audio-routing: A list of the connections between audio components.
Each entry is a pair of strings, the first being the
@@ -31,10 +33,10 @@ Required properties for the following compatibles:
"HP"
"HPCOM"
"LINEIN"
- "LINEOUT"
+ "LINEOUT" (not on sun8i-a23)
"MIC1"
"MIC2"
- "MIC3"
+ "MIC3" (sun6i-a31 only)
Microphone biases from the SoC:
"HBIAS"
@@ -48,6 +50,11 @@ Required properties for the following compatibles:
"Mic"
"Speaker"
+Required properties for the following compatibles:
+ - "allwinner,sun8i-a23-codec"
+- allwinner,codec-analog-controls: A phandle to the codec analog controls
+ block in the PRCM.
+
Example:
codec: codec at 01c22c00 {
#sound-dai-cells = <0>;
diff --git a/sound/soc/sunxi/sun4i-codec.c b/sound/soc/sunxi/sun4i-codec.c
index 092fdcf6de95..ada5fa055950 100644
--- a/sound/soc/sunxi/sun4i-codec.c
+++ b/sound/soc/sunxi/sun4i-codec.c
@@ -213,6 +213,10 @@
/* TODO sun6i DAP (Digital Audio Processing) bits */
+/* FIFO counters moved on A23 */
+#define SUN8I_A23_CODEC_DAC_TXCNT (0x1c)
+#define SUN8I_A23_CODEC_ADC_RXCNT (0x20)
+
struct sun4i_codec {
struct device *dev;
struct regmap *regmap;
@@ -1067,6 +1071,32 @@ static struct snd_soc_codec_driver sun6i_codec_codec = {
},
};
+/* sun8i A23 codec */
+static const struct snd_kcontrol_new sun8i_a23_codec_codec_controls[] = {
+ SOC_SINGLE_TLV("DAC Playback Volume", SUN4I_CODEC_DAC_DPC,
+ SUN4I_CODEC_DAC_DPC_DVOL, 0x3f, 1,
+ sun6i_codec_dvol_scale),
+};
+
+static const struct snd_soc_dapm_widget sun8i_a23_codec_codec_widgets[] = {
+ /* Digital parts of the ADCs */
+ SND_SOC_DAPM_SUPPLY("ADC Enable", SUN6I_CODEC_ADC_FIFOC,
+ SUN6I_CODEC_ADC_FIFOC_EN_AD, 0, NULL, 0),
+ /* Digital parts of the DACs */
+ SND_SOC_DAPM_SUPPLY("DAC Enable", SUN4I_CODEC_DAC_DPC,
+ SUN4I_CODEC_DAC_DPC_EN_DA, 0, NULL, 0),
+
+};
+
+static struct snd_soc_codec_driver sun8i_a23_codec_codec = {
+ .component_driver = {
+ .controls = sun8i_a23_codec_codec_controls,
+ .num_controls = ARRAY_SIZE(sun8i_a23_codec_codec_controls),
+ .dapm_widgets = sun8i_a23_codec_codec_widgets,
+ .num_dapm_widgets = ARRAY_SIZE(sun8i_a23_codec_codec_widgets),
+ },
+};
+
static const struct snd_soc_component_driver sun4i_codec_component = {
.name = "sun4i-codec",
};
@@ -1206,6 +1236,63 @@ static struct snd_soc_card *sun6i_codec_create_card(struct device *dev)
return card;
};
+/* Connect digital side enables to analog side widgets */
+static const struct snd_soc_dapm_route sun8i_codec_card_routes[] = {
+ /* ADC Routes */
+ { "Left ADC", NULL, "ADC Enable" },
+ { "Right ADC", NULL, "ADC Enable" },
+ { "Codec Capture", NULL, "Left ADC" },
+ { "Codec Capture", NULL, "Right ADC" },
+
+ /* DAC Routes */
+ { "Left DAC", NULL, "DAC Enable" },
+ { "Right DAC", NULL, "DAC Enable" },
+ { "Left DAC", NULL, "Codec Playback" },
+ { "Right DAC", NULL, "Codec Playback" },
+};
+
+static struct snd_soc_aux_dev aux_dev = {
+ .name = "Codec Analog Controls",
+};
+
+static struct snd_soc_card *sun8i_a23_codec_create_card(struct device *dev)
+{
+ struct snd_soc_card *card;
+ int ret;
+
+ card = devm_kzalloc(dev, sizeof(*card), GFP_KERNEL);
+ if (!card)
+ return ERR_PTR(-ENOMEM);
+
+ aux_dev.codec_of_node = of_parse_phandle(dev->of_node,
+ "allwinner,codec-analog-controls",
+ 0);
+ if (!aux_dev.codec_of_node) {
+ dev_err(dev, "Can't find analog controls for codec.\n");
+ return ERR_PTR(-EINVAL);
+ };
+
+ card->dai_link = sun4i_codec_create_link(dev, &card->num_links);
+ if (!card->dai_link)
+ return ERR_PTR(-ENOMEM);
+
+ card->dev = dev;
+ card->name = "A23 Audio Codec";
+ card->dapm_widgets = sun6i_codec_card_dapm_widgets;
+ card->num_dapm_widgets = ARRAY_SIZE(sun6i_codec_card_dapm_widgets);
+ card->dapm_routes = sun8i_codec_card_routes;
+ card->num_dapm_routes = ARRAY_SIZE(sun8i_codec_card_routes);
+ card->aux_dev = &aux_dev;
+ card->num_aux_devs = 1;
+ card->fully_routed = true;
+
+ ret = snd_soc_of_parse_audio_routing(card, "allwinner,audio-routing");
+ if (ret)
+ dev_warn(dev, "failed to parse audio-routing: %d\n", ret);
+
+ return card;
+};
+
static const struct regmap_config sun4i_codec_regmap_config = {
.reg_bits = 32,
.reg_stride = 4,
@@ -1227,6 +1314,13 @@ static const struct regmap_config sun7i_codec_regmap_config = {
.max_register = SUN7I_CODEC_AC_MIC_PHONE_CAL,
};
+static const struct regmap_config sun8i_a23_codec_regmap_config = {
+ .reg_bits = 32,
+ .reg_stride = 4,
+ .val_bits = 32,
+ .max_register = SUN8I_A23_CODEC_ADC_RXCNT,
+};
+
struct sun4i_codec_quirks {
const struct regmap_config *regmap_config;
const struct snd_soc_codec_driver *codec;
@@ -1265,6 +1359,16 @@ static const struct sun4i_codec_quirks sun7i_codec_quirks = {
.reg_adc_rxdata = SUN4I_CODEC_ADC_RXDATA,
};
+static const struct sun4i_codec_quirks sun8i_a23_codec_quirks = {
+ .regmap_config = &sun8i_a23_codec_regmap_config,
+ .codec = &sun8i_a23_codec_codec,
+ .create_card = sun8i_a23_codec_create_card,
+ .reg_adc_fifoc = REG_FIELD(SUN6I_CODEC_ADC_FIFOC, 0, 31),
+ .reg_dac_txdata = SUN4I_CODEC_DAC_TXDATA,
+ .reg_adc_rxdata = SUN6I_CODEC_ADC_RXDATA,
+ .has_reset = true,
+};
+
static const struct of_device_id sun4i_codec_of_match[] = {
{
.compatible = "allwinner,sun4i-a10-codec",
@@ -1278,6 +1382,10 @@ static const struct of_device_id sun4i_codec_of_match[] = {
.compatible = "allwinner,sun7i-a20-codec",
.data = &sun7i_codec_quirks,
},
+ {
+ .compatible = "allwinner,sun8i-a23-codec",
+ .data = &sun8i_a23_codec_quirks,
+ },
{}
};
MODULE_DEVICE_TABLE(of, sun4i_codec_of_match);
--
2.10.2
^ permalink raw reply related
* [PATCH v2 1/8] mfd: sun6i-prcm: Add codec analog controls sub-device for Allwinner A23
From: Chen-Yu Tsai @ 2016-11-25 12:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161125123442.28410-1-wens@csie.org>
The PRCM block on the A23 contains a message box like interface to
the registers for the analog path controls of the internal codec.
Add a sub-device for it.
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
---
drivers/mfd/sun6i-prcm.c | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/drivers/mfd/sun6i-prcm.c b/drivers/mfd/sun6i-prcm.c
index 011fcc555945..2b658bed47db 100644
--- a/drivers/mfd/sun6i-prcm.c
+++ b/drivers/mfd/sun6i-prcm.c
@@ -12,6 +12,9 @@
#include <linux/init.h>
#include <linux/of.h>
+#define SUN8I_CODEC_ANALOG_BASE 0x1c0
+#define SUN8I_CODEC_ANALOG_SIZE 0x4
+
struct prcm_data {
int nsubdevs;
const struct mfd_cell *subdevs;
@@ -57,6 +60,10 @@ static const struct resource sun6i_a31_apb0_rstc_res[] = {
},
};
+static const struct resource sun8i_codec_analog_res[] = {
+ DEFINE_RES_MEM(SUN8I_CODEC_ANALOG_BASE, SUN8I_CODEC_ANALOG_SIZE),
+};
+
static const struct mfd_cell sun6i_a31_prcm_subdevs[] = {
{
.name = "sun6i-a31-ar100-clk",
@@ -109,6 +116,12 @@ static const struct mfd_cell sun8i_a23_prcm_subdevs[] = {
.num_resources = ARRAY_SIZE(sun6i_a31_apb0_rstc_res),
.resources = sun6i_a31_apb0_rstc_res,
},
+ {
+ .name = "sun8i-codec-analog",
+ .of_compatible = "allwinner,sun8i-a23-codec-analog",
+ .num_resources = ARRAY_SIZE(sun8i_codec_analog_res),
+ .resources = sun8i_codec_analog_res,
+ },
};
static const struct prcm_data sun6i_a31_prcm_data = {
--
2.10.2
^ permalink raw reply related
* [PATCH v2 0/8] ASoC: sunxi: Add support for audio codec in A23/H3 SoCs
From: Chen-Yu Tsai @ 2016-11-25 12:34 UTC (permalink / raw)
To: linux-arm-kernel
Hi everyone,
This is v2 of my Allwinner A23 and H3 audio codec support series.
Changes since v1:
- Use DEFINE_RES_MEM for the analog path controls block resources.
- Added Rob's ack.
This series adds support for the audio codec found in Allwinner A23 and
H3 SoCs. The design and data paths are similar to the audio codec found
in earlier SoCs such as the A31. The analog audio paths are symmetrical
with left/right channels and down-mix selectors for mono differential
output.
What deviates from previous SoCs is that the analog path controls have
been moved to a separate control bus, accessed through a message box
like register interface in the PRCM block. This necessitates writing
a separate component driver for it, which is then tied into the sound
card as an ASoC auxiliary device.
Patch 1 adds the analog path controls block to the sun6i-prcm driver as
a sub-device, for the A23. The H3 currently does not use the PRCM driver.
Patch 2 adds PCM and card support for the A23 codec to the sun4i-codec
driver.
Patch 3 adds a device node for the analog path controls block to the A23
dtsi.
Patch 4 adds a device node for the audio codec, and the phandle for the
analog path controls block to the A23 dtsi.
Patch 5 enables the audio codec for the A23 Q8 tablets. On these tablets
the headphone output is driven in DC coupled, or "direct drive", mode.
Patch 6 adds PCM and card support for the H3 codec to the sun4i-codec
driver.
Patch 7 adds device nodes for the audio codec and analog path controls
block to the H3 dtsi.
Patch 8 enables the audio codec on the Orange Pi PC. The audio output
jack on the board is tied to the line out pins on the SoC.
Please take a look and let me know what you think.
In addition, the sun4i-codec driver is getting pretty large. Maybe we
want to split the different parts into different files?
Regards
ChenYu
Chen-Yu Tsai (8):
mfd: sun6i-prcm: Add codec analog controls sub-device for Allwinner
A23
ASoC: sun4i-codec: Add support for A23 codec
ARM: dts: sun8i: Add codec analog path controls node in PRCM for
A23/A33
ARM: dts: sun8i-a23: Add device node for internal audio codec
ARM: dts: sun8i-a23: q8-tablet: Enable internal audio codec
ASoC: sun4i-codec: Add support for H3 codec
ARM: dts: sun8i-h3: Add device nodes for audio codec and its analog
controls
ARM: dts: sun8i-h3: orange-pi-pc: Enable audio codec
.../devicetree/bindings/sound/sun4i-codec.txt | 14 +-
arch/arm/boot/dts/sun8i-a23-a33.dtsi | 4 +
arch/arm/boot/dts/sun8i-a23-q8-tablet.dts | 23 +++
arch/arm/boot/dts/sun8i-a23.dtsi | 16 ++
arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts | 8 +
arch/arm/boot/dts/sun8i-h3.dtsi | 19 +++
drivers/mfd/sun6i-prcm.c | 13 ++
sound/soc/sunxi/sun4i-codec.c | 179 +++++++++++++++++++++
8 files changed, 274 insertions(+), 2 deletions(-)
--
2.10.2
^ permalink raw reply
* [PATCH] arm64: mm: Fix memmap to be initialized for the entire section
From: Ard Biesheuvel @ 2016-11-25 12:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161125112914.GI2213@rric.localdomain>
On 25 November 2016 at 11:29, Robert Richter <robert.richter@cavium.com> wrote:
> On 24.11.16 19:42:47, Ard Biesheuvel wrote:
>> On 24 November 2016 at 19:26, Robert Richter <robert.richter@cavium.com> wrote:
>
>> > I revisited the code and it is working well already since:
>> >
>> > e7cd190385d1 arm64: mark reserved memblock regions explicitly in iomem
>> >
>> > Now, try_ram_remap() is only called if the region to be mapped is
>> > entirely in IORESOURCE_SYSTEM_RAM. This is only true for normal mem
>> > ranges and not NOMAP mem. region_intersects() then returns
>> > REGION_INTERSECTS and calls try_ram_remap(). For the NOMAP memory case
>> > REGION_DISJOINT would be returned and thus arch_memremap_wb() being
>> > called directly. Before the e7cd190385d1 change try_ram_remap() was
>> > called also for nomap regions.
>> >
>> > So we can leave memremap() as it is and just apply this patch
>> > unmodified. What do you think?
>>
>> I agree. The pfn_valid() check in try_ram_remap() is still appropriate
>> simply because the PageHighmem check requires a valid struct page. But
>> if we don't enter that code path anymore for NOMAP regions, I think
>> we're ok.
>>
>> > Please ack.
>> >
>>
>> I still don't fully understand how it is guaranteed that *all* memory
>> (i.e., all regions for which memblock_is_memory() returns true) is
>> covered by a struct page, but marked as reserved. Are we relying on
>> the fact that NOMAP memory is also memblock_reserve()'d?
>
> See free_low_memory_core_early():
>
> ----
> for_each_free_mem_range(i, NUMA_NO_NODE, MEMBLOCK_NONE, &start, &end,
> NULL)
> count += __free_memory_core(start, end);
> ----
>
> Only mem with the MEMBLOCK_NONE flag is added. And NOMAP pages are
> also *not* marked reserved. So nothing at all from NOMAP mem is
> reported to mm, it is not present (see below for a mem config, note
> flags: 0x4 mem regions).
>
OK, thanks for clearing that up. But that still does not explain how
we can be certain that NOMAP regions are guaranteed to be covered by a
struct page, does it? Because that is ultimately what pfn_valid()
means, that it is safe to, e.g., look at the page flags.
> [ 0.000000] efi: Processing EFI memory map:
> [ 0.000000] efi: 0x000001400000-0x00000147ffff [Conventional Memory| | | | | | | | |WB|WT|WC|UC]
> [ 0.000000] efi: 0x000001480000-0x0000024bffff [Loader Data | | | | | | | | |WB|WT|WC|UC]
> [ 0.000000] efi: 0x0000024c0000-0x0000211fffff [Conventional Memory| | | | | | | | |WB|WT|WC|UC]
> [ 0.000000] efi: 0x000021200000-0x00002121ffff [Loader Data | | | | | | | | |WB|WT|WC|UC]
> [ 0.000000] efi: 0x000021220000-0x0000fffebfff [Conventional Memory| | | | | | | | |WB|WT|WC|UC]
> [ 0.000000] efi: 0x0000fffec000-0x0000ffff5fff [ACPI Reclaim Memory| | | | | | | | |WB|WT|WC|UC]
> [ 0.000000] efi: 0x0000ffff6000-0x0000ffff6fff [ACPI Memory NVS | | | | | | | | |WB|WT|WC|UC]
> [ 0.000000] efi: 0x0000ffff7000-0x0000ffffffff [ACPI Reclaim Memory| | | | | | | | |WB|WT|WC|UC]
> [ 0.000000] efi: 0x000100000000-0x000ff7ffffff [Conventional Memory| | | | | | | | |WB|WT|WC|UC]
> [ 0.000000] efi: 0x000ff8000000-0x000ff801ffff [Boot Data | | | | | | | | |WB|WT|WC|UC]
> [ 0.000000] efi: 0x000ff8020000-0x000fffa9efff [Conventional Memory| | | | | | | | |WB|WT|WC|UC]
> [ 0.000000] efi: 0x000fffa9f000-0x000fffffffff [Boot Data | | | | | | | | |WB|WT|WC|UC]
> [ 0.000000] efi: 0x010000400000-0x010f816aefff [Conventional Memory| | | | | | | | |WB|WT|WC|UC]
> [ 0.000000] efi: 0x010f816af000-0x010f816b1fff [Loader Data | | | | | | | | |WB|WT|WC|UC]
> [ 0.000000] efi: 0x010f816b2000-0x010f826f1fff [Loader Code | | | | | | | | |WB|WT|WC|UC]
> [ 0.000000] efi: 0x010f826f2000-0x010f82701fff [Loader Data | | | | | | | | |WB|WT|WC|UC]
> [ 0.000000] efi: 0x010f82702000-0x010f82787fff [Boot Data | | | | | | | | |WB|WT|WC|UC]
> [ 0.000000] efi: 0x010f82788000-0x010f9276bfff [Loader Data | | | | | | | | |WB|WT|WC|UC]
> [ 0.000000] efi: 0x010f9276c000-0x010f9276cfff [Boot Data | | | | | | | | |WB|WT|WC|UC]
> [ 0.000000] efi: 0x010f9276d000-0x010f935a8fff [Loader Data | | | | | | | | |WB|WT|WC|UC]
> [ 0.000000] efi: 0x010f935a9000-0x010f93880fff [Boot Data | | | | | | | | |WB|WT|WC|UC]
> [ 0.000000] efi: 0x010f93881000-0x010ff7880fff [Loader Data | | | | | | | | |WB|WT|WC|UC]
> [ 0.000000] efi: 0x010ff7881000-0x010ff7886fff [Boot Data | | | | | | | | |WB|WT|WC|UC]
> [ 0.000000] efi: 0x010ff7887000-0x010ff78a3fff [Loader Code | | | | | | | | |WB|WT|WC|UC]
> [ 0.000000] efi: 0x010ff78a4000-0x010ff9e8dfff [Boot Data | | | | | | | | |WB|WT|WC|UC]
> [ 0.000000] efi: 0x010ff9e8e000-0x010ff9f16fff [Runtime Data |RUN| | | | | | | |WB|WT|WC|UC]
> [ 0.000000] efi: 0x010ff9f17000-0x010ffaeb5fff [Boot Data | | | | | | | | |WB|WT|WC|UC]
> [ 0.000000] efi: 0x010ffaeb6000-0x010ffafc8fff [Runtime Data |RUN| | | | | | | |WB|WT|WC|UC]
> [ 0.000000] efi: 0x010ffafc9000-0x010ffafccfff [Runtime Code |RUN| | | | | | | |WB|WT|WC|UC]
> [ 0.000000] efi: 0x010ffafcd000-0x010ffaff4fff [Runtime Data |RUN| | | | | | | |WB|WT|WC|UC]
> [ 0.000000] efi: 0x010ffaff5000-0x010ffb008fff [Conventional Memory| | | | | | | | |WB|WT|WC|UC]
> [ 0.000000] efi: 0x010ffb009000-0x010fffe28fff [Boot Data | | | | | | | | |WB|WT|WC|UC]
> [ 0.000000] efi: 0x010fffe29000-0x010fffe3ffff [Conventional Memory| | | | | | | | |WB|WT|WC|UC]
> [ 0.000000] efi: 0x010fffe40000-0x010fffe53fff [Loader Data | | | | | | | | |WB|WT|WC|UC]
> [ 0.000000] efi: 0x010fffe54000-0x010ffffb8fff [Boot Code | | | | | | | | |WB|WT|WC|UC]
> [ 0.000000] efi: 0x010ffffb9000-0x010ffffccfff [Runtime Code |RUN| | | | | | | |WB|WT|WC|UC]
> [ 0.000000] efi: 0x010ffffcd000-0x010fffffefff [Runtime Data |RUN| | | | | | | |WB|WT|WC|UC]
> [ 0.000000] efi: 0x010ffffff000-0x010fffffffff [Boot Data | | | | | | | | |WB|WT|WC|UC]
> [ 0.000000] efi: 0x804000001000-0x804000001fff [Memory Mapped I/O |RUN| | | | | | | | | | |UC]
> [ 0.000000] efi: 0x87e0d0001000-0x87e0d0001fff [Memory Mapped I/O |RUN| | | | | | | | | | |UC]
>
> [ 0.000000] MEMBLOCK configuration:
> [ 0.000000] memory size = 0x1ffe800000 reserved size = 0x39146a21
> [ 0.000000] memory.cnt = 0x9
> [ 0.000000] memory[0x0] [0x00000001400000-0x000000fffdffff], 0xfebe0000 bytes on node 0 flags: 0x0
> [ 0.000000] memory[0x1] [0x000000fffe0000-0x000000ffffffff], 0x20000 bytes on node 0 flags: 0x4
> [ 0.000000] memory[0x2] [0x00000100000000-0x00000fffffffff], 0xf00000000 bytes on node 0 flags: 0x0
> [ 0.000000] memory[0x3] [0x00010000400000-0x00010ff9e7ffff], 0xff9a80000 bytes on node 1 flags: 0x0
> [ 0.000000] memory[0x4] [0x00010ff9e80000-0x00010ff9f1ffff], 0xa0000 bytes on node 1 flags: 0x4
> [ 0.000000] memory[0x5] [0x00010ff9f20000-0x00010ffaeaffff], 0xf90000 bytes on node 1 flags: 0x0
> [ 0.000000] memory[0x6] [0x00010ffaeb0000-0x00010ffaffffff], 0x150000 bytes on node 1 flags: 0x4
> [ 0.000000] memory[0x7] [0x00010ffb000000-0x00010ffffaffff], 0x4fb0000 bytes on node 1 flags: 0x0
> [ 0.000000] memory[0x8] [0x00010ffffb0000-0x00010fffffffff], 0x50000 bytes on node 1 flags: 0x4
> [ 0.000000] reserved.cnt = 0xd
> [ 0.000000] reserved[0x0] [0x00000001480000-0x0000000249ffff], 0x1020000 bytes flags: 0x0
> [ 0.000000] reserved[0x1] [0x00000021200000-0x00000021210536], 0x10537 bytes flags: 0x0
> [ 0.000000] reserved[0x2] [0x000000c0000000-0x000000dfffffff], 0x20000000 bytes flags: 0x0
> [ 0.000000] reserved[0x3] [0x00000ffbfb8000-0x00000ffffdffff], 0x4028000 bytes flags: 0x0
> [ 0.000000] reserved[0x4] [0x00000ffffecb00-0x00000fffffffff], 0x13500 bytes flags: 0x0
> [ 0.000000] reserved[0x5] [0x00010f81780000-0x00010f8178ffff], 0x10000 bytes flags: 0x0
> [ 0.000000] reserved[0x6] [0x00010f82870000-0x00010f9286ffff], 0x10000000 bytes flags: 0x0
> [ 0.000000] reserved[0x7] [0x00010ffbce0000-0x00010fffceffff], 0x4010000 bytes flags: 0x0
> [ 0.000000] reserved[0x8] [0x00010fffee6d80-0x00010ffff2fffb], 0x4927c bytes flags: 0x0
> [ 0.000000] reserved[0x9] [0x00010ffff30000-0x00010ffffa000f], 0x70010 bytes flags: 0x0
> [ 0.000000] reserved[0xa] [0x00010ffffae280-0x00010ffffaff7f], 0x1d00 bytes flags: 0x0
> [ 0.000000] reserved[0xb] [0x00010ffffaffa0-0x00010ffffaffce], 0x2f bytes flags: 0x0
> [ 0.000000] reserved[0xc] [0x00010ffffaffd0-0x00010ffffafffe], 0x2f bytes flags: 0x0
^ permalink raw reply
* [PATCH 5/7] efi: Get the secure boot status [ver #3]
From: Ard Biesheuvel @ 2016-11-25 12:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <16661.1480075392@warthog.procyon.org.uk>
On 25 November 2016 at 12:03, David Howells <dhowells@redhat.com> wrote:
> How about the attached additional patch? Should I be checking the UEFI
> version number if such is available?
>
Yes. In pre-2.6, DeployedMode is not a reserved name, and so it may be
possible for someone to slip in a DeployedMode=0 on a secure boot
enabled system to trick the kernel into thinking lockdown should be
disabled.
> David
> ---
> commit 981110f45ba73798875af7639d0328dc2d6f9919
> Author: David Howells <dhowells@redhat.com>
> Date: Fri Nov 25 11:52:05 2016 +0000
>
> efi: Handle secure boot from UEFI-2.6
>
> UEFI-2.6 adds a new variable, DeployedMode. If it exists, this must be 1
> to engage lockdown mode.
>
> Reported-by: James Bottomley <James.Bottomley@HansenPartnership.com>
> Signed-off-by: David Howells <dhowells@redhat.com>
>
> diff --git a/drivers/firmware/efi/libstub/secureboot.c b/drivers/firmware/efi/libstub/secureboot.c
> index ca643eba5a4b..4c3bddef4fb3 100644
> --- a/drivers/firmware/efi/libstub/secureboot.c
> +++ b/drivers/firmware/efi/libstub/secureboot.c
> @@ -22,6 +22,9 @@ static const efi_char16_t const efi_SecureBoot_name[] = {
> static const efi_char16_t const efi_SetupMode_name[] = {
> 'S', 'e', 't', 'u', 'p', 'M', 'o', 'd', 'e', 0
> };
> +static const efi_char16_t const efi_DeployedMode_name[] = {
> + 'D', 'e', 'p', 'l', 'o', 'y', 'e', 'd', 'M', 'o', 'd', 'e', 0
> +};
>
> /* SHIM variables */
> static const efi_guid_t shim_guid = EFI_SHIM_LOCK_GUID;
> @@ -62,6 +65,16 @@ int efi_get_secureboot(efi_system_table_t *sys_table_arg)
> if (val == 1)
> return 0;
>
> + status = get_efi_var(efi_DeployedMode_name, &efi_variable_guid,
> + NULL, &size, &val);
> + if (status != EFI_NOT_FOUND) {
> + if (status != EFI_SUCCESS)
> + goto out_efi_err;
> +
> + if (val == 1)
> + return 0;
I think the logic is the wrong way around here. Secure Boot is enabled
if SecureBoot=1 and SetupMode=0, unless DeployedMode=0. So you should
return 0 here if val == 0, but only when running on 2.6 or later.
--
Ard.
^ permalink raw reply
* [RFC v2: PATCH 1/2] dt-bindings: Document the hi3660 reset bindings
From: zhangfei @ 2016-11-25 12:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480071241.4058.23.camel@pengutronix.de>
On 2016?11?25? 18:54, Philipp Zabel wrote:
> Am Freitag, den 25.11.2016, 18:42 +0800 schrieb zhangfei:
>> On 2016?11?25? 18:25, Philipp Zabel wrote:
>>> Am Donnerstag, den 24.11.2016, 18:20 +0800 schrieb zhangfei:
>>>> On 2016?11?24? 17:50, Philipp Zabel wrote:
>>>>> Am Donnerstag, den 24.11.2016, 17:40 +0800 schrieb zhangfei:
>>>>>> On 2016?11?24? 17:26, Philipp Zabel wrote:
>>>>>>> Am Mittwoch, den 23.11.2016, 16:07 +0800 schrieb Zhangfei Gao:
>>>>>>>> Add DT bindings documentation for hi3660 SoC reset controller.
>>>>>>>>
>>>>>>>> Signed-off-by: Zhangfei Gao <zhangfei.gao@linaro.org>
>>>>>>>> ---
>>>>>>>> .../bindings/reset/hisilicon,hi3660-reset.txt | 51 ++++++++++++++++++++++
>>>>>>>> 1 file changed, 51 insertions(+)
>>>>>>>> create mode 100644 Documentation/devicetree/bindings/reset/hisilicon,hi3660-reset.txt
>>>>>>>>
>>>>>>>> diff --git a/Documentation/devicetree/bindings/reset/hisilicon,hi3660-reset.txt b/Documentation/devicetree/bindings/reset/hisilicon,hi3660-reset.txt
>>>>>>>> new file mode 100644
>>>>>>>> index 0000000..250daf2
>>>>>>>> --- /dev/null
>>>>>>>> +++ b/Documentation/devicetree/bindings/reset/hisilicon,hi3660-reset.txt
>>>>>>>> @@ -0,0 +1,51 @@
>>>>>>>> +Hisilicon System Reset Controller
>>>>>>>> +======================================
>>>>>>>> +
>>>>>>>> +Please also refer to reset.txt in this directory for common reset
>>>>>>>> +controller binding usage.
>>>>>>>> +
>>>>>>>> +The reset controller registers are part of the system-ctl block on
>>>>>>>> +hi3660 SoC.
>>>>>>>> +
>>>>>>>> +Required properties:
>>>>>>>> +- compatible: should be
>>>>>>>> + "hisilicon,hi3660-reset"
>>>>>>>> +- #reset-cells: 1, see below
>>>>>>>> +- hisi,rst-syscon: phandle of the reset's syscon.
>>>>>>>> +- hisi,reset-bits: Contains the reset control register information
>>>>>>>> + Should contain 2 cells for each reset exposed to
>>>>>>>> + consumers, defined as:
>>>>>>>> + Cell #1 : offset from the syscon register base
>>>>>>>> + Cell #2 : bits position of the control register
>>>>>>>> +
>>>>>>>> +Example:
>>>>>>>> + iomcu: iomcu at ffd7e000 {
>>>>>>>> + compatible = "hisilicon,hi3660-iomcu", "syscon";
>>>>>>>> + reg = <0x0 0xffd7e000 0x0 0x1000>;
>>>>>>>> + };
>>>>>>>> +
>>>>>>>> + iomcu_rst: iomcu_rst_controller {
>>>>>>> This should be
>>>>>>> iomcu_rst: reset-controller {
>>>>>>>
>>>>>>>> + compatible = "hisilicon,hi3660-reset";
>>>>>>>> + #reset-cells = <1>;
>>>>>>>> + hisi,rst-syscon = <&iomcu>;
>>>>>>>> + hisi,reset-bits = <0x20 0x8 /* 0: i2c0 */
>>>>>>>> + 0x20 0x10 /* 1: i2c1 */
>>>>>>>> + 0x20 0x20 /* 2: i2c2 */
>>>>>>>> + 0x20 0x8000000>; /* 3: i2c6 */
>>>>>>>> + };
>>>>>>> The reset lines are controlled through iomcu bits, is there a reason not
>>>>>>> to put the iomcu_rst node inside the iomcu node? That way the
>>>>>>> hisi,rst-syscon property could be removed and the syscon could be
>>>>>>> retrieved via the reset-controller parent node.
>>>>>> iomcu is common registers, controls clock and reset, etc.
>>>>>> So we use syscon, without mapping the registers everywhere.
>>>>>> It is common case in hisilicon, same in hi6220.
>>>>>>
>>>>>> Also the #clock-cells and #reset-cells can not be put in the same node,
>>>>>> if they are both using probe, since reset_probe will not be called.
>>>>>>
>>>>>> So we use hisi,rst-syscon as a general solution.
>>>>> What I meant is this:
>>>>>
>>>>> iomcu: iomcu at ffd7e000 {
>>>>> compatible = "hisilicon,hi3660-iomcu", "syscon", "simple-mfd";
>>>>> reg = <0x0 0xffd7e000 0x0 0x1000>;
>>>> #clock-cells = <1>;
>>>>
>>>> In my test, if there add #clock-cells = <1>, reset_probe will not be
>>>> called any more.
>>>> Since clk_probe is called first.
>>>> No matter iomcu_rst is child node or not.
>>> I don't understand this, does the clock driver bind to the iomcu node
>>> using CLK_OF_DECLARE_DRIVER(..., "hisilicon,hi3660-iomcu", ...)?
>> This method:CLK_OF_DECLARE_DRIVER is not prefered in clock,
>> and we have to use probe instead, to make all driver build as modules as
>> possible.
>>
>> For example hi3660.
>> static struct platform_driver hi3660_clk_driver = {
>> .probe = hi3660_clk_probe,
>> .driver = {
>> .name = "hi3660-clk",
>> .of_match_table = hi3660_clk_match_table,
>> },
>> };
> hi3660_clk_match_table contains the "hisilicon,hi3660-iomcu" compatible?
> If so, you could call
> of_platform_populate(pdev->dev.of_node, NULL, NULL, &pdev->dev);
> from hi3660_clk_probe instead of using "simple-mfd" to probe the iomcu
> node's children.
Not using simple-mfd:
Like
static const struct of_device_id hi3660_clk_match_table[] = {
{ .compatible = "hisilicon,hi3660-iomcu", },
{ }
};
MODULE_DEVICE_TABLE(of, hi3660_clk_match_table);
static int hi3660_clk_probe(struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
struct device_node *np = pdev->dev.of_node;
const struct of_device_id *of_id;
enum hi3660_clk_type type;
of_id = of_match_device(hi3660_clk_match_table, dev);
if (!of_id)
return -EINVAL;
~
}
If put iomcu_rst as child node, and set #clock-cells = <1> to iomcu,
then hi3660_clk_probe is called, hi3660_reset_probe will not be called.
So using "hisi,rst-syscon" as pointer does not have the issue.
Thanks
^ permalink raw reply
* [PATCH V5 3/3] ARM64 LPC: LPC driver implementation on Hip06
From: Arnd Bergmann @ 2016-11-25 12:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <EE11001F9E5DDD47B7634E2F8A612F2E1F939E0A@lhreml507-mbx>
On Friday, November 25, 2016 8:46:11 AM CET Gabriele Paoloni wrote:
> > From: Arnd Bergmann [mailto:arnd at arndb.de]
> >
> > On Wednesday, November 23, 2016 6:07:11 PM CET Arnd Bergmann wrote:
> > > On Wednesday, November 23, 2016 3:22:33 PM CET Gabriele Paoloni
> > wrote:
> > > > From: Arnd Bergmann [mailto:arnd at arndb.de]
> > > > > On Friday, November 18, 2016 5:03:11 PM CET Gabriele Paoloni
> > /*
> > @@ -549,9 +548,14 @@ static int of_translate_one(struct device_node
> > *parent, struct of_bus *bus,
> > * that translation is impossible (that is we are not dealing with a
> > value
> > * that can be mapped to a cpu physical address). This is not really
> > specified
> > * that way, but this is traditionally the way IBM at least do things
> > + *
> > + * Whenever the translation fails, the *host pointer will be set to
> > the
> > + * device that lacks a tranlation, and the return code is relative to
> > + * that node.
>
> This seems to be wrong to me. We are abusing of the error conditions.
> So effectively if there is a buggy DT for an IO resource we end up
> assuming that we are using a special IO device with unmapped addresses.
>
> The patch at the bottom apply on top of this one and I think is a more
> reasonable approach
It was meant as a logical extension to the existing interface,
translating the address as far as we can, and reporting back
how far we got.
Maybe we can return 'of_root' by instead of NULL to signify
that we have converted all the way to the root of the DT?
That would make it more consistent, but slightly more complicated
for the common case.
> > */
> > static u64 __of_translate_address(struct device_node *dev,
> > - const __be32 *in_addr, const char *rprop)
> > + const __be32 *in_addr, const char *rprop,
> > + struct device_node **host)
> > {
> > struct device_node *parent = NULL;
> > struct of_bus *bus, *pbus;
> > @@ -564,6 +568,7 @@ static u64 __of_translate_address(struct
> > device_node *dev,
> > /* Increase refcount at current level */
> > of_node_get(dev);
> >
> > + *host = NULL;
> > /* Get parent & match bus type */
> > parent = of_get_parent(dev);
> > if (parent == NULL)
> > @@ -600,8 +605,9 @@ static u64 __of_translate_address(struct
> > device_node *dev,
> > pbus = of_match_bus(parent);
> > pbus->count_cells(dev, &pna, &pns);
> > if (!OF_CHECK_COUNTS(pna, pns)) {
> > - pr_err("Bad cell count for %s\n",
> > - of_node_full_name(dev));
> > + pr_debug("Bad cell count for %s\n",
> > + of_node_full_name(dev));
> > + *host = of_node_get(parent);
> > break;
> > }
> >
> > @@ -609,7 +615,9 @@ static u64 __of_translate_address(struct
> > device_node *dev,
> > pbus->name, pna, pns, of_node_full_name(parent));
> >
> > /* Apply bus translation */
> > - if (of_translate_one(dev, bus, pbus, addr, na, ns, pna,
> > rprop))
> > + result = of_translate_one(dev, bus, pbus, addr, na, ns,
> > + pna, rprop);
> > + if (result == OF_BAD_ADDR)
>
> It seems to me that here you missed "*host = of_node_get(parent);"..?
>
Yes, Zhichang also pointed out the same thing, this is not
right yet. My thought was that we need to check the #address-cells
and #size-cells of the parent node and return if they are not set,
but the bus should really have those.
What we need to do instead is check the "ranges" of the parent
and fail if there is no translation. Simply setting the host
here however won't work either because that leads to returning
OF_BAD_ADDR.
> > /* Complete the move up one level */
> > @@ -628,13 +636,32 @@ static u64 __of_translate_address(struct
> > device_node *dev,
> >
> > u64 of_translate_address(struct device_node *dev, const __be32
> > *in_addr)
> > {
> > - return __of_translate_address(dev, in_addr, "ranges");
> > + struct device_node *host;
...
> > +
> > phys_addr_t pci_pio_to_address(unsigned long pio)
> > {
> > phys_addr_t address = (phys_addr_t)OF_BAD_ADDR;
> > diff --git a/include/linux/pci.h b/include/linux/pci.h
> > index 6bd94a803e8f..b7a8fa3da3ca 100644
> > --- a/include/linux/pci.h
> > +++ b/include/linux/pci.h
> > @@ -1192,7 +1192,8 @@ int __must_check pci_bus_alloc_resource(struct
> > pci_bus *bus,
> > void *alignf_data);
[Many lines of reply trimmed here, please make sure you don't quote too
much context when you reply, it's really annoying to read through
it otherwise]
> /*
> + * of_isa_indirect_io - get the IO address from some isa reg property value.
> + * For some isa/lpc devices, no ranges property in ancestor node.
> + * The device addresses are described directly in their regs property.
> + * This fixup function will be called to get the IO address of isa/lpc
> + * devices when the normal of_translation failed.
> + *
> + * @parent: points to the parent dts node;
> + * @bus: points to the of_bus which can be used to parse address;
> + * @addr: the address from reg property;
> + * @na: the address cell counter of @addr;
> + * @presult: store the address paresed from @addr;
> + *
> + * return 1 when successfully get the I/O address;
> + * 0 will return for some failures.
> + */
> +static int of_get_isa_indirect_io(struct device_node *parent,
> + struct of_bus *bus, __be32 *addr,
> + int na, u64 *presult)
> +{
> + unsigned int flags;
> + unsigned int rlen;
> +
> + /* whether support indirectIO */
> + if (!indirect_io_enabled())
> + return 0;
> +
> + if (!of_bus_isa_match(parent))
> + return 0;
> +
> + flags = bus->get_flags(addr);
> + if (!(flags & IORESOURCE_IO))
> + return 0;
> +
> + /* there is ranges property, apply the normal translation directly. */
> + if (of_get_property(parent, "ranges", &rlen))
> + return 0;
> +
> + *presult = of_read_number(addr + 1, na - 1);
> + /* this fixup is only valid for specific I/O range. */
> + return addr_is_indirect_io(*presult);
> +}
Right, this would work. The reason I didn't go down this route is
that I wanted to keep it generic enough to allow doing the same
for PCI host bridges with a nonlinear mapping of the I/O space.
There isn't really anything special about ISA here, other than the
fact that the one driver that needs it happens to be for ISA rather
than PCI.
> +/*
> * Translate an address from the device-tree into a CPU physical address,
> * this walks up the tree and applies the various bus mappings on the
> * way.
> @@ -600,14 +643,23 @@ static u64 __of_translate_address(struct device_node *dev,
> result = of_read_number(addr, na);
> break;
> }
> + /*
> + * For indirectIO device which has no ranges property, get
> + * the address from reg directly.
> + */
> + if (of_get_isa_indirect_io(dev, bus, addr, na, &result)) {
> + pr_debug("isa indirectIO matched(%s)..addr = 0x%llx\n",
> + of_node_full_name(dev), result);
> + *host = of_node_get(parent);
> + break;
> + }
>
If we do the special case for ISA as you suggest above, I would still want
to keep it in of_translate_ioport(), I think that's a useful change by
itself in my patch.
Arnde
^ permalink raw reply
* [PATCH 5/7] efi: Get the secure boot status [ver #3]
From: David Howells @ 2016-11-25 12:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKv+Gu_JxNLDjaK5jGbX9ACzM0uHJYMOFx7XDo4t7DtBMtFRGA@mail.gmail.com>
How about the attached additional patch? Should I be checking the UEFI
version number if such is available?
David
---
commit 981110f45ba73798875af7639d0328dc2d6f9919
Author: David Howells <dhowells@redhat.com>
Date: Fri Nov 25 11:52:05 2016 +0000
efi: Handle secure boot from UEFI-2.6
UEFI-2.6 adds a new variable, DeployedMode. If it exists, this must be 1
to engage lockdown mode.
Reported-by: James Bottomley <James.Bottomley@HansenPartnership.com>
Signed-off-by: David Howells <dhowells@redhat.com>
diff --git a/drivers/firmware/efi/libstub/secureboot.c b/drivers/firmware/efi/libstub/secureboot.c
index ca643eba5a4b..4c3bddef4fb3 100644
--- a/drivers/firmware/efi/libstub/secureboot.c
+++ b/drivers/firmware/efi/libstub/secureboot.c
@@ -22,6 +22,9 @@ static const efi_char16_t const efi_SecureBoot_name[] = {
static const efi_char16_t const efi_SetupMode_name[] = {
'S', 'e', 't', 'u', 'p', 'M', 'o', 'd', 'e', 0
};
+static const efi_char16_t const efi_DeployedMode_name[] = {
+ 'D', 'e', 'p', 'l', 'o', 'y', 'e', 'd', 'M', 'o', 'd', 'e', 0
+};
/* SHIM variables */
static const efi_guid_t shim_guid = EFI_SHIM_LOCK_GUID;
@@ -62,6 +65,16 @@ int efi_get_secureboot(efi_system_table_t *sys_table_arg)
if (val == 1)
return 0;
+ status = get_efi_var(efi_DeployedMode_name, &efi_variable_guid,
+ NULL, &size, &val);
+ if (status != EFI_NOT_FOUND) {
+ if (status != EFI_SUCCESS)
+ goto out_efi_err;
+
+ if (val == 1)
+ return 0;
+ }
+
/* See if a user has put shim into insecure mode. If so, and if the
* variable doesn't have the runtime attribute set, we might as well
* honor that.
^ permalink raw reply related
* [net-next PATCH v1 0/2] stmmac: dwmac-meson8b: configurable RGMII TX delay
From: Måns Rullgård @ 2016-11-25 12:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <6a6af561-4e83-ca6e-d989-f421e18bce1e@laposte.net>
Sebastian Frias <sf84@laposte.net> writes:
> On 24/11/16 19:55, Florian Fainelli wrote:
>> Le 24/11/2016 ? 09:05, Martin Blumenstingl a ?crit :
>>> Based on what I found it seems that rgmii-id, rgmii-txid and
>>> rgmii-rxid are supposed to be handled by the PHY.
>>
>> Correct, the meaning of PHY_INTERFACE_MODE should be from the
>> perspective of the PHY device:
>>
>> - PHY_INTERFACE_MODE_RGMII_TXID means that the PHY is responsible for
>> adding a delay when the MAC transmits (TX MAC -> PHY (delay) -> wire)
>> - PHY_INTERFACE_MODE_RGMII_RXID means that the PHY is responsible for
>> adding a delay when the MAC receives (RX MAC <- (delay) PHY) <- wire)
>>
>
> Thanks for the explanation.
> Actually I had thought that the delay was to account for board routing
> (wires) between the MAC and the PHY.
> From your explanation it appears that the delay is to account for board
> routing (wires) between the PHY and the RJ45 socket.
The delay pertains to the RGMII link between MAC and PHY. The external
connection is self-clocking.
--
M?ns Rullg?rd
^ permalink raw reply
* Tearing down DMA transfer setup after DMA client has finished
From: Måns Rullgård @ 2016-11-25 11:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161125045549.GC2698@localhost>
Vinod Koul <vinod.koul@intel.com> writes:
> On Wed, Nov 23, 2016 at 11:25:44AM +0100, Mason wrote:
>> Hello,
>>
>> On my platform, setting up a DMA transfer is a two-step process:
>>
>> 1) configure the "switch box" to connect a device to a memory channel
>> 2) configure the transfer details (address, size, command)
>>
>> When the transfer is done, the sbox setup can be torn down,
>> and the DMA driver can start another transfer.
>>
>> The current software architecture for my NFC (NAND Flash controller)
>> driver is as follows (for one DMA transfer).
>>
>> sg_init_one
>> dma_map_sg
>> dmaengine_prep_slave_sg
>> dmaengine_submit
>> dma_async_issue_pending
>> configure_NFC_transfer
>> wait_for_IRQ_from_DMA_engine // via DMA_PREP_INTERRUPT
>> wait_for_NFC_idle
>> dma_unmap_sg
>
> Looking at thread and discussion now, first thinking would be to ensure
> the transaction is completed properly and then isr fired. You may need
> to talk to your HW designers to find a way for that. It is quite common
> that DMA controllers will fire and complete whereas the transaction is
> still in flight.
The hardware is what it is, and it has been deployed in some form or
other for years.
> If that is not doable, then since you claim this is custom part which
> other vendors wont use (hope we are wrong down the line), then we can
> have a custom api,
>
> foo_sbox_configure(bool enable, ...);
>
> This can be invoked from NFC driver when required for configuration and
> teardown. For very specific cases where people need some specific
> configuration we do allow custom APIs.
>
> Only problem with that would be it wont be a generic solution and you
> seem to be fine with that.
The same DMA unit is also used for SATA, which is an off the shelf
Designware controller with an in-kernel driver. This interrupt timing
glitch can actually explain some intermittent errors I've observed with
it.
One possible solution is to add a new function for device drivers to
call when their end is complete. Existing DMA drivers would simply do
nothing, and device drivers could have this call added whenever the need
arises.
--
M?ns Rullg?rd
^ permalink raw reply
* [PATCH 2/2] clk: uniphier: add clock data for cpufreq
From: Masahiro Yamada @ 2016-11-25 11:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161124021056.GJ6095@codeaurora.org>
Hi Stephen,
2016-11-24 11:10 GMT+09:00 Stephen Boyd <sboyd@codeaurora.org>:
>> If I drop 32bit SoC things, and send v2 only for 64bit SoCs,
>> is that acceptable for 4.10-rc1?
>
> Sure. That sounds fine for now. I'll reply to your other thread
> with a plan of attack on how to do the framework changes. I think
> we need to do those regardless of the outcome of your
> investigation.
I posted v2 yesterday.
--
Best Regards
Masahiro Yamada
^ permalink raw reply
* [PATCH V7 2/3] ACPI: Add support for ResourceSource/IRQ domain mapping
From: Lorenzo Pieralisi @ 2016-11-25 11:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161124161548.GA11766@red-moon>
Hi Agustin,
On Thu, Nov 24, 2016 at 04:15:48PM +0000, Lorenzo Pieralisi wrote:
[...]
> > @@ -448,6 +449,7 @@ bool acpi_dev_resource_interrupt(struct acpi_resource *ares, int index,
> > {
> > struct acpi_resource_irq *irq;
> > struct acpi_resource_extended_irq *ext_irq;
> > + struct fwnode_handle *src;
> >
> > switch (ares->type) {
> > case ACPI_RESOURCE_TYPE_IRQ:
> > @@ -460,7 +462,7 @@ bool acpi_dev_resource_interrupt(struct acpi_resource *ares, int index,
> > acpi_dev_irqresource_disabled(res, 0);
> > return false;
> > }
> > - acpi_dev_get_irqresource(res, irq->interrupts[index],
> > + acpi_dev_get_irqresource(res, irq->interrupts[index], NULL,
> > irq->triggering, irq->polarity,
> > irq->sharable, true);
> > break;
> > @@ -470,7 +472,8 @@ bool acpi_dev_resource_interrupt(struct acpi_resource *ares, int index,
> > acpi_dev_irqresource_disabled(res, 0);
> > return false;
> > }
> > - acpi_dev_get_irqresource(res, ext_irq->interrupts[index],
> > + src = acpi_get_irq_source_fwhandle(&ext_irq->resource_source);
>
> Is there a reason why we need to do the domain look-up here ?
>
> I would like to understand if, by reshuffling the code (and by returning
> the resource_source to the calling code - somehow), it would be possible
> to just mirror what the OF code does in of_irq_get(), namely:
>
> (1) parse the irq entry -> of_irq_parse_one()
> (2) look the domain up -> irq_find_host()
> (3) create the mapping -> irq_create_of_mapping()
>
> You wrote the code already, I think it is just a matter of shuffling
> it around (well, minus returning the resource_source to the caller
> which is phandle equivalent in DT).
>
> You abstracted away (2) and (3) behind acpi_register_irq(), that
> on anything than does not use ACPI_GENERIC_GSI is just glue code
> to acpi_register_gsi().
>
> Also, it is not a question on this patch but I ask it here because it
> is related. On ACPI you are doing the reverse of what is done in
> DT in platform_get_irq():
>
> - get the resources already parsed -> platform_get_resource()
> - if they are disabled -> acpi_irq_get()
>
> and I think the ordering is tied to my question above because
> you carry out the domain look up in acpi_dev_resource_interrupt()
> so that if for any reason it fails the corresponding resource
> is disabled so that we try to get it again through acpi_irq_get().
>
> I suspect you did it this way to make sure:
>
> a) keep the current ACPI IRQ parsing interface changes to a mininum
> b) avoid changing the behaviour on x86/ia64; in particular, calling
> acpi_register_gsi() for the _same_ mapping (an IRQ that was already
> registered at device creation resource parsing) multiple times can
> trigger issues on x86/ia64
>
> I think that's a reasonable approach but I wanted to get these
> clarifications, I do not think you are far from getting this
> done but since it is a significant change I think it is worth
> discussing the points I raised above because I think the DT code
> sequence in of_irq_get() (1-2-3 above) is cleaner from an IRQ
> layer perspective (instead of having the domain look-up buried
> inside the ACPI IRQ resource parsing API).
I had another look and to achieve the above one way of doing that is to
implement acpi_irq_get() only for ACPI_GENERIC_GSI and stub it out for
!ACPI_GENERIC_GSI (ie return an error code so that on !ACPI_GENERIC_GSI
we would fall back to current solution for ACPI). Within acpi_irq_get()
you can easily carry out the same steps (1->2->3) above in ACPI you have
the code already there I think it is easy to change the
acpi_irq_get_cb() interface to return a filled in struct irq_fwspec and
the interface would become identical to of_irq_get() that is an
advantage to maintain it from an IRQ maintainership perspective I think,
that's my opinion.
There is still a nagging snag though. When platform devices are
created, core ACPI code parse the resources through:
acpi_dev_get_resources()
and we _have_ to have way to avoid initializing IRQ resources that
have a dependency (ie there is a resource_source pointer that is valid
in their descriptors) that's easy to do if we think that's the right
thing to do and can hardly break current code (which ignores the
resource_source altogether).
It is an important difference with DT probing, where the IRQ
resources are only created if the domain reference (ie interrupt
controller phandle) is satisfied at of_device_alloc() time
(see of_device_alloc()).
Thoughts ? Please let me know, the code to implement what I say
is already in these patches, it is just a matter of reshuffling it.
Thanks !
Lorenzo
^ permalink raw reply
* [PATCH] arm64: mm: Fix memmap to be initialized for the entire section
From: Robert Richter @ 2016-11-25 11:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKv+Gu_C_17RtAiw2U0OOzVik3G7KkwUTo5eiGK-HDo-maQ-bA@mail.gmail.com>
On 24.11.16 19:42:47, Ard Biesheuvel wrote:
> On 24 November 2016 at 19:26, Robert Richter <robert.richter@cavium.com> wrote:
> > I revisited the code and it is working well already since:
> >
> > e7cd190385d1 arm64: mark reserved memblock regions explicitly in iomem
> >
> > Now, try_ram_remap() is only called if the region to be mapped is
> > entirely in IORESOURCE_SYSTEM_RAM. This is only true for normal mem
> > ranges and not NOMAP mem. region_intersects() then returns
> > REGION_INTERSECTS and calls try_ram_remap(). For the NOMAP memory case
> > REGION_DISJOINT would be returned and thus arch_memremap_wb() being
> > called directly. Before the e7cd190385d1 change try_ram_remap() was
> > called also for nomap regions.
> >
> > So we can leave memremap() as it is and just apply this patch
> > unmodified. What do you think?
>
> I agree. The pfn_valid() check in try_ram_remap() is still appropriate
> simply because the PageHighmem check requires a valid struct page. But
> if we don't enter that code path anymore for NOMAP regions, I think
> we're ok.
>
> > Please ack.
> >
>
> I still don't fully understand how it is guaranteed that *all* memory
> (i.e., all regions for which memblock_is_memory() returns true) is
> covered by a struct page, but marked as reserved. Are we relying on
> the fact that NOMAP memory is also memblock_reserve()'d?
See free_low_memory_core_early():
----
for_each_free_mem_range(i, NUMA_NO_NODE, MEMBLOCK_NONE, &start, &end,
NULL)
count += __free_memory_core(start, end);
----
Only mem with the MEMBLOCK_NONE flag is added. And NOMAP pages are
also *not* marked reserved. So nothing at all from NOMAP mem is
reported to mm, it is not present (see below for a mem config, note
flags: 0x4 mem regions).
-Robert
[ 0.000000] efi: Processing EFI memory map:
[ 0.000000] efi: 0x000001400000-0x00000147ffff [Conventional Memory| | | | | | | | |WB|WT|WC|UC]
[ 0.000000] efi: 0x000001480000-0x0000024bffff [Loader Data | | | | | | | | |WB|WT|WC|UC]
[ 0.000000] efi: 0x0000024c0000-0x0000211fffff [Conventional Memory| | | | | | | | |WB|WT|WC|UC]
[ 0.000000] efi: 0x000021200000-0x00002121ffff [Loader Data | | | | | | | | |WB|WT|WC|UC]
[ 0.000000] efi: 0x000021220000-0x0000fffebfff [Conventional Memory| | | | | | | | |WB|WT|WC|UC]
[ 0.000000] efi: 0x0000fffec000-0x0000ffff5fff [ACPI Reclaim Memory| | | | | | | | |WB|WT|WC|UC]
[ 0.000000] efi: 0x0000ffff6000-0x0000ffff6fff [ACPI Memory NVS | | | | | | | | |WB|WT|WC|UC]
[ 0.000000] efi: 0x0000ffff7000-0x0000ffffffff [ACPI Reclaim Memory| | | | | | | | |WB|WT|WC|UC]
[ 0.000000] efi: 0x000100000000-0x000ff7ffffff [Conventional Memory| | | | | | | | |WB|WT|WC|UC]
[ 0.000000] efi: 0x000ff8000000-0x000ff801ffff [Boot Data | | | | | | | | |WB|WT|WC|UC]
[ 0.000000] efi: 0x000ff8020000-0x000fffa9efff [Conventional Memory| | | | | | | | |WB|WT|WC|UC]
[ 0.000000] efi: 0x000fffa9f000-0x000fffffffff [Boot Data | | | | | | | | |WB|WT|WC|UC]
[ 0.000000] efi: 0x010000400000-0x010f816aefff [Conventional Memory| | | | | | | | |WB|WT|WC|UC]
[ 0.000000] efi: 0x010f816af000-0x010f816b1fff [Loader Data | | | | | | | | |WB|WT|WC|UC]
[ 0.000000] efi: 0x010f816b2000-0x010f826f1fff [Loader Code | | | | | | | | |WB|WT|WC|UC]
[ 0.000000] efi: 0x010f826f2000-0x010f82701fff [Loader Data | | | | | | | | |WB|WT|WC|UC]
[ 0.000000] efi: 0x010f82702000-0x010f82787fff [Boot Data | | | | | | | | |WB|WT|WC|UC]
[ 0.000000] efi: 0x010f82788000-0x010f9276bfff [Loader Data | | | | | | | | |WB|WT|WC|UC]
[ 0.000000] efi: 0x010f9276c000-0x010f9276cfff [Boot Data | | | | | | | | |WB|WT|WC|UC]
[ 0.000000] efi: 0x010f9276d000-0x010f935a8fff [Loader Data | | | | | | | | |WB|WT|WC|UC]
[ 0.000000] efi: 0x010f935a9000-0x010f93880fff [Boot Data | | | | | | | | |WB|WT|WC|UC]
[ 0.000000] efi: 0x010f93881000-0x010ff7880fff [Loader Data | | | | | | | | |WB|WT|WC|UC]
[ 0.000000] efi: 0x010ff7881000-0x010ff7886fff [Boot Data | | | | | | | | |WB|WT|WC|UC]
[ 0.000000] efi: 0x010ff7887000-0x010ff78a3fff [Loader Code | | | | | | | | |WB|WT|WC|UC]
[ 0.000000] efi: 0x010ff78a4000-0x010ff9e8dfff [Boot Data | | | | | | | | |WB|WT|WC|UC]
[ 0.000000] efi: 0x010ff9e8e000-0x010ff9f16fff [Runtime Data |RUN| | | | | | | |WB|WT|WC|UC]
[ 0.000000] efi: 0x010ff9f17000-0x010ffaeb5fff [Boot Data | | | | | | | | |WB|WT|WC|UC]
[ 0.000000] efi: 0x010ffaeb6000-0x010ffafc8fff [Runtime Data |RUN| | | | | | | |WB|WT|WC|UC]
[ 0.000000] efi: 0x010ffafc9000-0x010ffafccfff [Runtime Code |RUN| | | | | | | |WB|WT|WC|UC]
[ 0.000000] efi: 0x010ffafcd000-0x010ffaff4fff [Runtime Data |RUN| | | | | | | |WB|WT|WC|UC]
[ 0.000000] efi: 0x010ffaff5000-0x010ffb008fff [Conventional Memory| | | | | | | | |WB|WT|WC|UC]
[ 0.000000] efi: 0x010ffb009000-0x010fffe28fff [Boot Data | | | | | | | | |WB|WT|WC|UC]
[ 0.000000] efi: 0x010fffe29000-0x010fffe3ffff [Conventional Memory| | | | | | | | |WB|WT|WC|UC]
[ 0.000000] efi: 0x010fffe40000-0x010fffe53fff [Loader Data | | | | | | | | |WB|WT|WC|UC]
[ 0.000000] efi: 0x010fffe54000-0x010ffffb8fff [Boot Code | | | | | | | | |WB|WT|WC|UC]
[ 0.000000] efi: 0x010ffffb9000-0x010ffffccfff [Runtime Code |RUN| | | | | | | |WB|WT|WC|UC]
[ 0.000000] efi: 0x010ffffcd000-0x010fffffefff [Runtime Data |RUN| | | | | | | |WB|WT|WC|UC]
[ 0.000000] efi: 0x010ffffff000-0x010fffffffff [Boot Data | | | | | | | | |WB|WT|WC|UC]
[ 0.000000] efi: 0x804000001000-0x804000001fff [Memory Mapped I/O |RUN| | | | | | | | | | |UC]
[ 0.000000] efi: 0x87e0d0001000-0x87e0d0001fff [Memory Mapped I/O |RUN| | | | | | | | | | |UC]
[ 0.000000] MEMBLOCK configuration:
[ 0.000000] memory size = 0x1ffe800000 reserved size = 0x39146a21
[ 0.000000] memory.cnt = 0x9
[ 0.000000] memory[0x0] [0x00000001400000-0x000000fffdffff], 0xfebe0000 bytes on node 0 flags: 0x0
[ 0.000000] memory[0x1] [0x000000fffe0000-0x000000ffffffff], 0x20000 bytes on node 0 flags: 0x4
[ 0.000000] memory[0x2] [0x00000100000000-0x00000fffffffff], 0xf00000000 bytes on node 0 flags: 0x0
[ 0.000000] memory[0x3] [0x00010000400000-0x00010ff9e7ffff], 0xff9a80000 bytes on node 1 flags: 0x0
[ 0.000000] memory[0x4] [0x00010ff9e80000-0x00010ff9f1ffff], 0xa0000 bytes on node 1 flags: 0x4
[ 0.000000] memory[0x5] [0x00010ff9f20000-0x00010ffaeaffff], 0xf90000 bytes on node 1 flags: 0x0
[ 0.000000] memory[0x6] [0x00010ffaeb0000-0x00010ffaffffff], 0x150000 bytes on node 1 flags: 0x4
[ 0.000000] memory[0x7] [0x00010ffb000000-0x00010ffffaffff], 0x4fb0000 bytes on node 1 flags: 0x0
[ 0.000000] memory[0x8] [0x00010ffffb0000-0x00010fffffffff], 0x50000 bytes on node 1 flags: 0x4
[ 0.000000] reserved.cnt = 0xd
[ 0.000000] reserved[0x0] [0x00000001480000-0x0000000249ffff], 0x1020000 bytes flags: 0x0
[ 0.000000] reserved[0x1] [0x00000021200000-0x00000021210536], 0x10537 bytes flags: 0x0
[ 0.000000] reserved[0x2] [0x000000c0000000-0x000000dfffffff], 0x20000000 bytes flags: 0x0
[ 0.000000] reserved[0x3] [0x00000ffbfb8000-0x00000ffffdffff], 0x4028000 bytes flags: 0x0
[ 0.000000] reserved[0x4] [0x00000ffffecb00-0x00000fffffffff], 0x13500 bytes flags: 0x0
[ 0.000000] reserved[0x5] [0x00010f81780000-0x00010f8178ffff], 0x10000 bytes flags: 0x0
[ 0.000000] reserved[0x6] [0x00010f82870000-0x00010f9286ffff], 0x10000000 bytes flags: 0x0
[ 0.000000] reserved[0x7] [0x00010ffbce0000-0x00010fffceffff], 0x4010000 bytes flags: 0x0
[ 0.000000] reserved[0x8] [0x00010fffee6d80-0x00010ffff2fffb], 0x4927c bytes flags: 0x0
[ 0.000000] reserved[0x9] [0x00010ffff30000-0x00010ffffa000f], 0x70010 bytes flags: 0x0
[ 0.000000] reserved[0xa] [0x00010ffffae280-0x00010ffffaff7f], 0x1d00 bytes flags: 0x0
[ 0.000000] reserved[0xb] [0x00010ffffaffa0-0x00010ffffaffce], 0x2f bytes flags: 0x0
[ 0.000000] reserved[0xc] [0x00010ffffaffd0-0x00010ffffafffe], 0x2f bytes flags: 0x0
^ permalink raw reply
* [PATCH v3 2/3] powerpc/reloc64: add support for 32-bit CRC pseudo-symbols
From: Michael Ellerman @ 2016-11-25 11:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477585631-18574-3-git-send-email-ard.biesheuvel@linaro.org>
Ard Biesheuvel <ard.biesheuvel@linaro.org> writes:
> diff --git a/arch/powerpc/relocs_check.sh b/arch/powerpc/relocs_check.sh
> index ec2d5c835170..2f510fbc87da 100755
> --- a/arch/powerpc/relocs_check.sh
> +++ b/arch/powerpc/relocs_check.sh
> @@ -43,7 +43,8 @@ R_PPC_ADDR16_HA
> R_PPC_RELATIVE
> R_PPC_NONE' |
> grep -E -v '\<R_PPC64_ADDR64[[:space:]]+mach_' |
> - grep -E -v '\<R_PPC64_ADDR64[[:space:]]+__crc_'
> + grep -E -v '\<R_PPC64_ADDR64[[:space:]]+__crc_' |
> + grep -E -v '\<R_PPC64_ADDR32[[:space:]]+\*ABS\*'
I'm still getting:
WARNING: 24 bad relocations
c000000000d307c4 R_PPC64_ADDR32 __crc___arch_hweight16
c000000000d307c8 R_PPC64_ADDR32 __crc___arch_hweight32
c000000000d307cc R_PPC64_ADDR32 __crc___arch_hweight64
c000000000d307d0 R_PPC64_ADDR32 __crc___arch_hweight8
c000000000d30848 R_PPC64_ADDR32 __crc___bswapdi2
c000000000d30854 R_PPC64_ADDR32 __crc___clear_user
c000000000d30868 R_PPC64_ADDR32 __crc___copy_tofrom_user
c000000000d30d4c R_PPC64_ADDR32 __crc__mcount
c000000000d31344 R_PPC64_ADDR32 __crc_copy_page
c000000000d3141c R_PPC64_ADDR32 __crc_current_stack_pointer
c000000000d31840 R_PPC64_ADDR32 __crc_empty_zero_page
c000000000d31a7c R_PPC64_ADDR32 __crc_flush_dcache_range
c000000000d31a84 R_PPC64_ADDR32 __crc_flush_icache_range
c000000000d32608 R_PPC64_ADDR32 __crc_load_fp_state
c000000000d32614 R_PPC64_ADDR32 __crc_load_vr_state
c000000000d32828 R_PPC64_ADDR32 __crc_memchr
c000000000d32830 R_PPC64_ADDR32 __crc_memcmp
c000000000d32834 R_PPC64_ADDR32 __crc_memcpy
c000000000d32840 R_PPC64_ADDR32 __crc_memmove
c000000000d32888 R_PPC64_ADDR32 __crc_memset
c000000000d33c9c R_PPC64_ADDR32 __crc_store_fp_state
c000000000d33ca0 R_PPC64_ADDR32 __crc_store_vr_state
c000000000d33cf0 R_PPC64_ADDR32 __crc_strncmp
c000000000d33cf4 R_PPC64_ADDR32 __crc_strncpy
If I just add those to the whitelist it builds, but then things aren't
happy@boot:
[ 7.607687] kvm: disagrees about version of symbol module_layout
[ 7.846799] virtio: disagrees about version of symbol module_layout
[ 22.012615] crc32c_vpmsum: disagrees about version of symbol module_layout
[ 22.012959] libcrc32c: disagrees about version of symbol module_layout
cheers
^ 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