IRQ storm: unmasked Rx interrupt happens again
and again is misprocessed in the same way.
This patch fixes that scenario by unmasking Rx interrupts only when
napi_complete_done() returns true, which means it has cleared
NAPIF_STATE_SCHED in state.
Signed-off-by: Nikita Yushchenko
---
drivers
>> Kernel currently does, but it is caught in
>> mv88e6xxx_port_check_hw_vlan() and returns -ENOTSUPP from there.
>
> But VID 0 has a special meaning for the kernel, it means the port's private
> database (when it is isolated, non-bridged), it is not meant to be programmed
> in the switch. That's
31.05.2019 17:37, Andrew Lunn wrote:
>> I'm not sure that I like the semantic of it, because the driver can actually
>> support VID 0 per-se, only the kernel does not use VLAN 0. Thus I would avoid
>> calling the port_vlan_del() ops for VID 0, directly into the upper DSA layer.
>>
>> Florian, An
In the current code, __media_pipeline_start() skips check of
MEDIA_PAD_FL_MUST_CONNECT logic for entity not providing link_validate()
op.
Fix that by checking for existence of link_validate() at different code
location.
Signed-off-by: Nikita Yushchenko
---
drivers/media/mc/mc-entity.c | 6
This change allows phytool [1] and similar tools to read and write C45 phy
registers from userspace.
This is useful for debugging and for porting vendor phy diagnostics tools.
[1] https://github.com/wkz/phytool
Signed-off-by: Nikita Yushchenko
---
drivers/net/phy/phy.c | 17
then this error code is explicitly cleared in
dsa_slave_vlan_rx_kill_vid() and error message is no longer logged.
Signed-off-by: Nikita Yushchenko
---
drivers/net/dsa/mv88e6xxx/chip.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/ne
When non-bridged, non-vlan'ed mv88e6xxx port is moving down, error
message is logged:
failed to kill vid 0081/0 for device eth_cu_1000_4
This is caused by call from __vlan_vid_del() with vin set to zero, over
call chain this results into _mv88e6xxx_port_vlan_del() called with
vid=0, and mv88e6xxx
> There are three boards that share that configuration almost to a T,
> with the only difference is the particular GPIOs used. Putting it into
> a common file avoids repeating the boilerplate and makes it explicit
> to the reader that those settings are shared.
I'd agree if that boilerplate was 10
> + i2c_gpio: i2c-gpio {
> + compatible = "i2c-gpio";
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_swi2c>;
> + i2c-gpio,delay-us = <50>;
> + status = "okay";
> +
> + #address-cells = <1>;
> + #size-c
To fix that add a pinmux configuration line configureing the pad to
> function as a GPIO. While we are at it, add a corresponding
> output-high GPIO hog in an effort to minimize current consumption.
>
> Cc: Nikita Yushchenko
> Cc: Shawn Guo
> Cc: Fabio Estevam
> Cc: Lucas Stac
This adds rave-sp powerbutton and backlight devices to RDU1 device tree.
Signed-off-by: Nikita Yushchenko
---
arch/arm/boot/dts/imx51-zii-rdu1.dts | 8
1 file changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/imx51-zii-rdu1.dts
b/arch/arm/boot/dts/imx51-zii-rdu1.dts
index
On RDU1, sdhc1 is used for eMMC, and that is 3.3V only.
Thus configure device node not to probe it as SD/SDIO and not try 1.8V.
Signed-off-by: Nikita Yushchenko
---
arch/arm/boot/dts/imx51-zii-rdu1.dts | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm/boot/dts/imx51-zii-rdu1.dts
Vybrid has single internal temperature sensor connected to both internal
ADC modules.
vf610-zii-dev already has ADC0 enabled. Now, to get temperature sensor
captured by iio_hwmon driver, need to configure iio_hwmon node to use
that ADC.
Signed-off-by: Nikita Yushchenko
---
arch/arm/boot/dts
On RDU1, imx51 usbh1 interface is either not used, or used via external
block that breaks USB2 signalling.
To keep things working if high-speed device gets connected to that
block, use ChipIdea feature to limit port to full speed.
Signed-off-by: Nikita Yushchenko
---
arch/arm/boot/dts/imx51
This fixes errors in RDU1 device tree that cause touch screens not
working.
Signed-off-by: Nikita Yushchenko
---
arch/arm/boot/dts/imx51-zii-rdu1.dts | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/imx51-zii-rdu1.dts
b/arch/arm/boot/dts/imx51-zii
Use SET_SYSTEM_SLEEP_PM_OPS() macro instead of direct assignment to
.suspend and .resume fields.
This makes driver working after restore from hibernation.
Signed-off-by: Nikita Yushchenko
---
sound/soc/sh/rcar/core.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/sound
Use SET_LATE_SYSTEM_SLEEP_PM_OPS() macro instead of direct assignment to
.resume_early field.
This fixes initialization of CS2000 in restore from hibernation in case
of kernel used to load image did not initialize CS2000 while kernel
being restored had CS2000 initialized.
Signed-off-by: Nikita
Hi
For those who care about linux RT behavior:
while analyzing traces, just found priority inversion caused by RT task
calling cancel_work_sync(), while work item in question is executing in
non-RT kworker that was preempted for significant time.
WBR,
Nikita Yushchenko
>> I think that trying to make this generic is purely synthetic. This
>> information is board-specific per it's nature, it comes from what board
>> is designed for, different boards have quite different sets of possible
>> reset reasons. What is needed is - pass this board-specific information
>> t
30.08.2017 23:38, Pavel Machek wrote:
> Hi!
>
+ * 9 -> Illegal Trap
+ * 10 -> Unknown
+ * 11 -> Crew Panel Requested
>>>
>>> Anyway... If you move management chip to .. I don't know, i2c, the
>>> path would change. Also it would be
for common use case. Full (and cumbersome)
implementation can be added later if ever needed.
Signed-off-by: Nikita Yushchenko
Reviewed-by: Linus Walleij
Tested-by: Aleksander Morgado
---
drivers/rtc/Kconfig | 10 +-
drivers/rtc/rtc-ds1307.c | 13 +
2 files changed,
This adds support for reading and writing date/time from/to ds1314 chip.
Other functionality (alarms, inout clock, output clock) is not added
yet, because availability of that depends on chip connections.
Signed-off-by: Nikita Yushchenko
---
drivers/rtc/Kconfig | 10 +-
drivers
>> - Thinking further on this, I realized that for common case signal
>> polarity is something defined by chip, and thus this knowledge belongs
>> to chip's driver and not to chip user's device tree. Moreover, device
>> tree writer could easily be not aware of signal polarity (too many
>> datasheet
>> Still, isn't there subsystem-level default that all events are disabled
>> by default? If such, then current hi8435 state breaks subsystem-level
>> rules, which is a [userspace-visible] bug. I'm not sure how far should
>> we go in bug compatibility.
>
> It is indeed the subsystem default (as m
>> +&edma1 {
>> +status = "okay";
>> +};
>> +
>> +&dspi2 {
>
> Please keep these labelled nodes sort alphabetically.
Ok
>> +bus-num = <1>;
>> +pinctrl-names = "default";
>> +pinctrl-0 = <&pinctrl_dspi2>;
>> +status = "okay";
>
> We usually have 'status' line at the bottom of
>> "Crap origin" here is that in vast majority of cases, polarity is
>> per-chip, not per-chip-use, knowledge. And proper location for per-chip
>> knowledge is chip's driver. Moving this knowledge to per-chip-use
>> location in device trees only provides a source for errors, with little
>> gain.
>
> Reset GPIO is active low.
>
> Currently driver uses gpiod_set_value(1) to clean reset, which depends
> on device tree to contain GPIO_ACTIVE_HIGH - that does not match reality.
>
> This fixes driver to use _raw version of gpiod_set_value() to enforce
> active-low seman
24.05.2017 22:27, Jonathan Cameron wrote:
> On Tue, 23 May 2017 11:08:30 +0300
> Nikita Yushchenko wrote:
>
>> Having all events enabled by default is misleading.
>> Userspace should explicitly enable events they want to receive.
>>
>> Signed-off-by: Nikita Y
>> Add locking to avoid interference between reading/processing current
>> sence in event enable and event generation paths.
>>
>> Signed-off-by: Nikita Yushchenko
> Make sense. Could you give a little more detail on the seriousness
> of this bug? I need to asse
>> Reset GPIO is active low.
>>
>> Currently driver uses gpiod_set_value(1) to clean reset, which depends
>> on device tree to contain GPIO_ACTIVE_HIGH - that does not match reality.
>>
>> This fixes driver to use _raw version of gpiod_set_value() to enforce
>> active-low semantics despite of what'
Having all events enabled by default is misleading.
Userspace should explicitly enable events they want to receive.
Signed-off-by: Nikita Yushchenko
---
drivers/iio/adc/hi8435.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/iio/adc/hi8435.c b/drivers/iio/adc/hi8435.c
index
C syntax allows apersands when initializing structures fields with
function pointers, but in Linux sources ampersands are normally not used
in thix context.
Signed-off-by: Nikita Yushchenko
---
drivers/iio/adc/hi8435.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a
Add locking to avoid interference between reading/processing current
sence in event enable and event generation paths.
Signed-off-by: Nikita Yushchenko
---
drivers/iio/adc/hi8435.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/iio/adc/hi8435.c b/drivers/iio/adc/hi8435.c
>> +int ret;
>> +u32 tmp;
>> +
>> +if (state) {
>> +ret = hi8435_readl(priv, HI8435_SO31_0_REG, &tmp);
>> +if (ret < 0)
>> +return ret;
>> +if (tmp & BIT(chan->channel))
>> +priv->event_prev_val |= BIT(chan->channel);
>> +else
>> +
>> However, hi8435 driver historically was coded using inverted values
>> passed to gpiolib calls. And there are setups in the wild with device
>> trees containing GPIO_ACTIVE_HIGH that I'd prefer not breaking.
>>
>> To solve, I submitted a patch on hi8435 driver that changes to _raw()
>> gpio cal
Hi,
Alternative solution could be - have separate write path for earlycon.
>>>
>>> It looks to me having the same issue with a separate write patch
>>> for earlycon as we still need distinguish Little or Big endian
>>> for Layerscape and IMX.
>>>
At a glance, it is dozen lines of code.
>
>> +hi8435@1 {
>> +compatible = "holt,hi8435";
>> +reg = <1>;
>> +spi-max-frequency = <2000>;
>> +gpios = <&gpio5 3 0>;
>
> Nit: GPIO_ACTIVE_HIGH instead of 0?
Gray area here.
Chip's reset input is active LOW.
However, hi8435 driver histor
Propagate error return from dspi_request_dma() into probe routine's
return.
Signed-off-by: Nikita Yushchenko
---
drivers/spi/spi-fsl-dspi.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/spi/spi-fsl-dspi.c b/drivers/spi/spi-fsl-dspi.c
index 1520164
ZII dev board rev B has a Holt Hi8435 connected to dspi2.
Add it to device tree.
ZII dev board rev C does not have that, so use rev-b dts file,
not common dtsi file.
Signed-off-by: Nikita Yushchenko
---
arch/arm/boot/dts/vf610-zii-dev-rev-b.dts | 19 +++
1 file changed, 19
es reliable sequence for userspace:
- enable event,
- AFTER THAT read current value,
- AFTER THAT each event will correspond to change.
Signed-off-by: Nikita Yushchenko
---
drivers/iio/adc/hi8435.c | 15 +--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/drivers/iio/ad
Possible values of sensing_mode are encoded with strings and actual
atrings used are not obvious.
Provide a hint by enabling in_voltage_sensing_mode_available attribute.
Signed-off-by: Nikita Yushchenko
---
drivers/iio/adc/hi8435.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers
With current event-only driver, it is not possible for user space
application to know current senses if they don't change since
application starts.
Address that by adding raw access to channels.
Signed-off-by: Nikita Yushchenko
---
drivers/iio/adc/hi8435.c | 22 ++
1
en in device tree. Allowing
device tree to override that only opens possibility for errors and does
not add any value.
Additionally, use _cansleep version to make things work with i2c-gpio
and other sleeping gpio drivers.
Signed-off-by: Nikita Yushchenko
---
drivers/iio/adc/hi8435.c | 12 +++---
Hi
My view of your statement is:
- you currently assume only a few cases for this driver - builtin UART
in vf610, ls1012a and imx7,
- in each of these cases, all lpuart instances share same endian, thus
having that in global var works for these cases,
- having that in global var makes it possible
>> Code should be consistent.
>>
>
> Yes.
>
>> There is no good reason to have sport->lpuart32 inside sport, but
>> lpuart_is_be outside of it. Both these values describe properties of
>> particular device, and thus should be in per-device structure.
>>
>
> That's for special case, normally we w
> static u32 lpuart32_read(void __iomem *addr)
> {
> - return ioread32be(addr);
> + return lpuart_is_be ? ioread32be(addr) : readl(addr);
> }
>
> static void lpuart32_write(u32 val, void __iomem *addr)
> {
> - iowrite32be(val, addr);
> + if (lpuart_is_
>>> @@ -2000,6 +2007,7 @@ static int lpuart_probe(struct platform_device *pdev)
>>> }
>>> sport->port.line = ret;
>>> sport->lpuart32 = sdata->is_32;
>>> + lpuart_is_be = sdata->is_be;
>>
>> Setting a global variable in per-device routine is quite bad design.
>>
>
> There is a reason
17.05.2017 06:39, Dong Aisheng wrote:
> On Tue, May 16, 2017 at 02:15:08PM +0300, Nikita Yushchenko wrote:
>>> static u32 lpuart32_read(void __iomem *addr)
>>> {
>>> - return ioread32be(addr);
>>> + return lpuart_is_be ? ioread32be(addr) : rea
> static u32 lpuart32_read(void __iomem *addr)
> {
> - return ioread32be(addr);
> + return lpuart_is_be ? ioread32be(addr) : readl(addr);
> }
>
> static void lpuart32_write(u32 val, void __iomem *addr)
> {
> - iowrite32be(val, addr);
> + if (lpuart_is_be)
> + iowr
> @@ -2000,6 +2007,7 @@ static int lpuart_probe(struct platform_device *pdev)
> }
> sport->port.line = ret;
> sport->lpuart32 = sdata->is_32;
> + lpuart_is_be = sdata->is_be;
Setting a global variable in per-device routine is quite bad design.
>> +/*
>> + * If pctldev is not null, we are claiming hog for it,
>> + * that means, setting that is served by pctldev by itself.
>> + *
>> + * Thus we must skip map that is for this device but is served
>> + * by other device.
et to pinctrl device being registered. Need also check that
map's control device is also set to the same.
Signed-off-by: Nikita Yushchenko
---
drivers/pinctrl/core.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/pinctrl/core.c b/drivers/pinctrl/core.c
index 1653
>>> Maybe create_pinctrl() could check if the pin controller device
>>> for a potential hog points to the device itself and bail out
>>> if that's not the case?
>>
>> Well that's exactly what patch from my first mail in this thread does.
>> This indeed fixes my case, but I don't know if it is corre
>>> Hmm maybe yeah. I don't quite follow the above the "pinctrl-0 property
>>> of sx150x device tree node, is misinterpreted as hog" part though.
>>
>> sx150x is i2c-gpio device. It has 16 GPIO lines that are communicated
>> with via i2c bus, and an interrupt line.
>>
>> Interrupt line is typicall
> Hmm maybe yeah. I don't quite follow the above the "pinctrl-0 property
> of sx150x device tree node, is misinterpreted as hog" part though.
sx150x is i2c-gpio device. It has 16 GPIO lines that are communicated
with via i2c bus, and an interrupt line.
Interrupt line is typically connected to So
Hi
Looks like recent pinctrl changes - possibly commit 99e4f67508e1
("pinctrl: core: Use delayed work for hogs") - breaks pinctrl-sx150x
driver in all setups where it has any pinctrl settings in device tree.
AFAIU, pinctrl-sx150x is not a real pinctrl/pinmux driver, but it uses
pinctrl subsystem
> Hi,
>
> your commit 80cca775cdc4f8555612d2943a2872076b33e0ff breaks Linux
> booting in qemu-system-m68k:
Hi.
Do you compile with CONFIG_M5272?
Is f85de347c974cdf97b1026180995d912d7d0 also in your tree?
Nikita
>> There is a use cases when architecture is 64-bit but hardware supports
>> only DMA to lower 4G of address space. E.g. NVMe device on RCar PCIe host.
>>
>> For such cases, it looks proper to call blk_queue_bounce_limit() with
>> mask set to 0x - thus making block layer to use bounce buff
Hmm, I think when the dma-ranges are missing, we should either enforce
a 32-bit mask, or disallow DMA completely. It's probably too late for
the latter, I wish we had done this earlier in order to force everyone
on ARM64 to have a valid dma-ranges property for any DMA master.
12.01.2017 08:52, Nikita Yushchenko wrote:
>>> diff --git a/drivers/staging/fsl-mc/bus/fsl-mc-bus.c
>>> b/drivers/staging/fsl-mc/bus/fsl-mc-bus.c
>>> index 5ac373c..480b644 100644
>>> --- a/drivers/staging/fsl-mc/bus/fsl-mc-bus.c
>>> +++ b/drivers/
>> diff --git a/drivers/staging/fsl-mc/bus/fsl-mc-bus.c
>> b/drivers/staging/fsl-mc/bus/fsl-mc-bus.c
>> index 5ac373c..480b644 100644
>> --- a/drivers/staging/fsl-mc/bus/fsl-mc-bus.c
>> +++ b/drivers/staging/fsl-mc/bus/fsl-mc-bus.c
>> @@ -540,7 +540,7 @@ int fsl_mc_device_add(struct dprc_obj_desc
>> @@ -959,6 +990,15 @@ void arch_setup_dma_ops(struct device *dev, u64
>> dma_base, u64 size,
>> if (!dev->archdata.dma_ops)
>> dev->archdata.dma_ops = &swiotlb_dma_ops;
>>
>> + /*
>> +* Whatever the parent bus can set. A device must not set
>> +* a
-by: Nikita Yushchenko
---
lib/swiotlb.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/lib/swiotlb.c b/lib/swiotlb.c
index 975b8fc..a8d74a7 100644
--- a/lib/swiotlb.c
+++ b/lib/swiotlb.c
@@ -483,11 +483,11 @@ phys_addr_t swiotlb_tbl_map_single(struct device *hwdev
ional boolean argument to
arch_setup_dma_ops() to show if range originates from authorative source
and thus should be enforced, or is just a guess and should be handled as
such.
Signed-off-by: Nikita Yushchenko
---
arch/arm/include/asm/dma-mapping.h | 1 +
arch/arm/mm/dma-mapp
> I reckon the easiest way forward would be to pass in some flag to
> arch_setup_dma_ops to indicate whether it's an explicitly-configured
> range or not - then simply initialising parent_dma_mask to ~0 for the
> default case *should* keep things working as before.
Tried to do t
evice
capabilities. To avoid breakage, actual mask must not be set wider than
device connection allows.
Signed-off-by: Nikita Yushchenko
CC: Arnd Bergmann
CC: Robin Murphy
CC: Will Deacon
---
arch/arm64/Kconfig | 3 +++
arch/arm64/include/asm/device.h | 1 +
arch/arm64/in
> I actually have a third variation of this problem involving a PCI root
> complex which *could* drive full-width (40-bit) addresses, but won't,
> due to the way its PCI<->AXI interface is programmed. That would require
> even more complicated dma-ranges handling to describe the windows of
> valid
>> What issue "IOMMU doesn't solve"?
>>
>> Issue I'm trying to address is - inconsistency within swiotlb
>> dma_map_ops, where (1) any wide mask is silently accepted, but (2) then
>> mask is used to decide if bounce buffers are needed or not. This
>> inconsistency causes NVMe+R-Car cobmo not workin
Hi
> The point here is that an IOMMU doesn't solve your issue, and the
> IOMMU-backed DMA ops need the same treatment. In light of that, it really
> feels to me like the DMA masks should be restricted in of_dma_configure
> so that the parent mask is taken into account there, rather than hook
> int
eeded here.
Nikita
> On Tue, Jan 10, 2017 at 09:47:21AM +0300, Nikita Yushchenko wrote:
>> I'm now working with HW that:
>> - is now way "low end" or "obsolete", it has 4G of RAM and 8 CPU cores,
>> and is being manufactured and developed,
>>
>> I believe the bounce buffering code you refer to is not in SATA/SCSI/MMC
>> but in block layer, in particular it should be controlled by
>> blk_queue_bounce_limit(). [Yes there is CONFIG_MMC_BLOCK_BOUNCE but it
>> is something completely different, namely it is for request merging for
>> hw not
Hi
There is a use cases when architecture is 64-bit but hardware supports
only DMA to lower 4G of address space. E.g. NVMe device on RCar PCIe host.
For such cases, it looks proper to call blk_queue_bounce_limit() with
mask set to 0x - thus making block layer to use bounce buffers
for any
[CCing NVMe maintainers since we are discussion issues in that driver]
>> With my patch applied and thus 32bit dma_mask set for NVMe device, I do
>> see high addresses passed to dma_map_*() routines and handled by
>> swiotlb. Thus your statement that behavior "succeed 64bit dma_set_mask()
>> opera
>>> I run into same issue and posted a patch:
>>
>>> "ASoC: Fix binding and probing of auxiliary components".
>>
>> Which I applied so I guess things are fine now without the revert? I'm
>> still working through backlog from the holidays so didn't check
>> properly yet.
>
> This fixes the Allwinn
and dev->dma_coherent_mask must still keep values
that hardware handles physically.
This patch enforces that. Based on original version by
Arnd Bergmann , extended with coherent mask hadnling.
Signed-off-by: Nikita Yushchenko
CC: Arnd Bergmann
---
Changes since v1:
- fixed issues noted by Serg
>> +if (mask > dev->archdata.parent_dma_mask)
>> +mask = dev->archdata.parent_dma_mask;
>> +
>> +
>
>One empty line is enough...
Ok
>> +/*
>> + * Whatever the parent bus can set. A device must not set
>> + * a DMA mask larger than this.
>> + */
>> +dev->archda
and dev->dma_coherent_mask must still keep values
that hardware handles physically.
This patch enforces that. Based on original version by
Arnd Bergmann , extended with coherent mask hadnling.
Signed-off-by: Nikita Yushchenko
CC: Arnd Bergmann
---
... now with initially missed change in arch_se
and dev->dma_coherent_mask must still keep values
that hardware handles physically.
This patch enforces that. Based on original version by
Arnd Bergmann , extended with coherent mask hadnling.
Signed-off-by: Nikita Yushchenko
CC: Arnd Bergmann
---
arch/arm64/Kconfig | 3 +++
>>> Just a guess, but if the inbound translation windows in the host
>>> bridge are wider than 32-bit, the reason for setting up a single
>>> 32-bit window is probably because that is what the parent bus supports.
I've re-checked rcar-pcie hardware documentation.
It indeed mentions that AXI bus i
For OF platforms, this is called via of_dma_configure(), that checks
dma-ranges of node that is *parent* for host bridge. Host bridge
currently does not control this at all.
>>>
>>> We need to think about this a bit. Is it actually the PCI host
>>> bridge that limits the ranges here,
>> For OF platforms, this is called via of_dma_configure(), that checks
>> dma-ranges of node that is *parent* for host bridge. Host bridge
>> currently does not control this at all.
>
> We need to think about this a bit. Is it actually the PCI host
> bridge that limits the ranges here, or the bus
> commit 9a57d58d116800a535510053136c6dd7a9c26e25
> Author: Arnd Bergmann
> Date: Tue Nov 17 14:06:55 2015 +0100
>
> [EXPERIMENTAL] ARM64: check implement dma_set_mask
>
> Needs work for coherent mask
>
> Signed-off-by: Arnd Bergmann
Unfortunately this is far incomplete
diff --git a/arch/arm64/mm/dma-mapping.c b/arch/arm64/mm/dma-mapping.c
index 290a84f..49645277 100644
--- a/arch/arm64/mm/dma-mapping.c
+++ b/arch/arm64/mm/dma-mapping.c
@@ -28,6 +28,7 @@
#include
#include
#include
+#include
#include
t;
>> This is the least destructive approach: currently dma_mask of that device
>> object is not used anyhow, thus all existing setups will work as before,
>> and modification is required only in actually affected components -
>> driver of particular PCI host bridge, and dma_
Some drivers (e.g. nvme) do depend on page mappings to be page
aligned.
Swiotlb already enforces such alignment for mappings greater than page,
extend that to page-sized mappings as well.
Signed-off-by: Nikita Yushchenko
---
lib/swiotlb.c | 6 +++---
1 file changed, 3 insertions(+), 3
Hi
> &dev_attr_properties.attr,
> + &dev_arrr_disable.attr,
Typo here.
After fixing that,
Tested-by: Nikita Yushchenko
on is required only in actually affected components -
driver of particular PCI host bridge, and dma_map_ops of particular
platform.
Signed-off-by: Nikita Yushchenko
---
arch/arm64/mm/dma-mapping.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/arch/arm64/mm/dma-mapping.c b/arch/arm64/
This gives platform DMA mapping code a chance to disallow setting device
DMA mask to something that host bridge can't support.
Signed-off-by: Nikita Yushchenko
---
drivers/pci/host/pcie-rcar.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/pci/host/pcie-rcar.c b/driver
>> This reverts commit 1a653aa44725668590b36bbe2d7fe4736a69f055 ("ASoC:
>> core: replace aux_comp_list to component_dev_list").
>>
>> That commit tries to remove card->aux_comp_list, using flagged entries
>> in card->component_dev_list instead.
>>
>> However, components are added to card->component
soc_probe_component() was not yet called for them.
Thus all aux devices are lost and any setup that needs them no longer
works.
Signed-off-by: Nikita Yushchenko
---
Fixed lost line in commit message ;)
include/sound/soc.h | 4 +++-
sound/soc/soc-core.c | 17 +
2 files cha
aux devices are lost and any setup that needs them no longer
works.
Signed-off-by: Nikita Yushchenko
---
include/sound/soc.h | 4 +++-
sound/soc/soc-core.c | 17 +
2 files changed, 8 insertions(+), 13 deletions(-)
diff --git a/include/sound/soc.h b/include/sound/soc.h
index 2
Hi
Is lkml.org supported?
Currently:
- [headers] link on top of pages does not show message headers,
- [forward] link on top of pages is not functional - it requests text
from captcha but does not show image.
[forward] could be useful to get a list mail that one did not receive,
to be able to
> If trying to avoid big changes and only fixing particular problem with
> particular device not working on arm64, I think best way is to
> alter__swiotlb_dma_supported() in arch/arm64/mm/dma-mapping.c to detect
> and decline (with -EIO) mask that is unsupported by device connection.
> This will co
>> Thus recommended dma_set_mask_and_coherent() call, instead of checking
>> if platform supports 64-bit DMA addressing, unconditionally enables
>> 64-bit DMA addressing. In case of device actually can't do DMA to 64-bit
>> addresses (e.g. because of limitations in PCIe controller), this breaks
>>
Andrey Smirnov
Tested-by: Nikita Yushchenko
> Remove 'fixed-link' nodes from DSA ports since they are not needed (they
> are not limiting link's speed and the ports will be configured to their
> maximux speed as a default)
>
> Suggested-by: Andrew Lunn
> Signed-off-by: Andrey Smirnov
With this patch, ports connected to revB's second switc
f where such restriction might be inconvenient,
> consider a hardware design where "rstn" is connected to a pin of I2C/SPI
> GPIO expander chip.
>
> Cc: Chris Healy
> Signed-off-by: Andrey Smirnov
Reviewed-by: Nikita Yushchenko
> Anyway, regardless of my comments above:
>
> Teseted-by: Andrey Smirnov
Thanks.
Just sent v3 with all comments worked on.
Nikita
ly
Signed-off-by: Nikita Yushchenko
Tested-by: Andrey Smirnov
---
Changes since v2:
- restructured per suggesions by Andrey Smirnov:
- returned register access routines back to recalc_rate() / set_rate(),
- renamed mf <-> rate convertion routines
- fixed spelling errors.
Changes since v1
Hi.
Per Documentation/DMA-API-HOWTO.txt, driver of device capable of 64-bit
DMA addressing, should call dma_set_mask_and_coherent(dev,
DMA_BIT_MASK(64)) and if that succeeds, assume that 64-bit DMA
addressing is available.
This behaves incorrectly on arm64 system (Renesas r8a7795-h3ulcb) here.
-
1 - 100 of 198 matches
Mail list logo
