BMC/Intel-BMC/linux.git/include/linux, branch dev-5.8-intel

soc: aspeed: mctp: Export function used to read BDF

2021-02-04T13:16:07+00:00

Recently, aspeed-mctp driver functionality was extended to store BDF values for already discovered MCTP endpoints on PCIe bus. Let's expose kernel API to read BDF based on endpoint ID. Change-Id: I146e67a8c2f4f541b4c3065c18dcadf531f30670 Signed-off-by: Iwona Winiarska

Update I3C drivers

2021-01-08T02:22:52+00:00

This commit ports I3C updates from Aspeed SDK v00.06.00. Note: Should be refined to get upstreamed. Signed-off-by: Dylan Hung Change-Id: Ic674bf5d6b5e72b389c739b136710915aabc6324

fixup! soc: aspeed: mctp: Expose internal kernel API

2021-01-07T01:18:44+00:00

Fixed a missing error handling for case where wait_event_interruptible_timeout() returns -ERESTARTSYS. Renamed the exposed functions to be more consistent with their usage. Added dedicated function to flush client rx queue. Change-Id: I0fd1bfca926b34ae0f4dc18f07e453b3861a4c3e Signed-off-by: Iwona Winiarska

peci: Add peci_revision property

2020-12-17T09:19:12+00:00

Right now, PECI revision is determined using a result of GetDIB() PECI command. Because GetDIB() may not be supported by all type of physical media that provides PECI, we need an alternative. Until we figure how to determine PECI revision there (if we can't do that, we'll fallback to device tree), let's allow to hardcode PECI revision as a property of hardware adapter. Change-Id: Iea75ccae9b9f793c67e996064fff3c31c730ad4f Signed-off-by: Iwona Winiarska

soc: aspeed: mctp: Expose internal kernel API

2020-12-17T09:19:12+00:00

Some protocols that are already implemented in kernel can be encapsulated in MCTP packets. To allow use aspeed-mctp internally in kernel space, let's allow to use selected functions outside of aspeed-mctp. Change-Id: I543bfce975dfdd7cf8017899a139f69febbaca8d Signed-off-by: Iwona Winiarska

Merge v5.8.17, commit '6d07b544ce203a684d9ca52635dcf2f4fc89b7d4' into dev-5.8-intel

2020-11-05T01:31:53+00:00

Merge tag 'v5.8.17' into dev-5.8

2020-10-30T02:37:00+00:00

This is the 5.8.17 stable release Signed-off-by: Joel Stanley

dmaengine: dw: Add DMA-channels mask cell support

2020-10-29T09:08:29+00:00

[ Upstream commit e8ee6c8cb61b676f1a2d6b942329e98224bd8ee9 ] DW DMA IP-core provides a way to synthesize the DMA controller with channels having different parameters like maximum burst-length, multi-block support, maximum data width, etc. Those parameters both explicitly and implicitly affect the channels performance. Since DMA slave devices might be very demanding to the DMA performance, let's provide a functionality for the slaves to be assigned with DW DMA channels, which performance according to the platform engineer fulfill their requirements. After this patch is applied it can be done by passing the mask of suitable DMA-channels either directly in the dw_dma_slave structure instance or as a fifth cell of the DMA DT-property. If mask is zero or not provided, then there is no limitation on the channels allocation. For instance Baikal-T1 SoC is equipped with a DW DMAC engine, which first two channels are synthesized with max burst length of 16, while the rest of the channels have been created with max-burst-len=4. It would seem that the first two channels must be faster than the others and should be more preferable for the time-critical DMA slave devices. In practice it turned out that the situation is quite the opposite. The channels with max-burst-len=4 demonstrated a better performance than the channels with max-burst-len=16 even when they both had been initialized with the same settings. The performance drop of the first two DMA-channels made them unsuitable for the DW APB SSI slave device. No matter what settings they are configured with, full-duplex SPI transfers occasionally experience the Rx FIFO overflow. It means that the DMA-engine doesn't keep up with incoming data pace even though the SPI-bus is enabled with speed of 25MHz while the DW DMA controller is clocked with 50MHz signal. There is no such problem has been noticed for the channels synthesized with max-burst-len=4. Signed-off-by: Serge Semin Link: https://lore.kernel.org/r/20200731200826.9292-6-Sergey.Semin@baikalelectronics.ru Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin

bpf: Limit caller's stack depth 256 for subprogs with tailcalls

2020-10-29T09:08:24+00:00

[ Upstream commit 7f6e4312e15a5c370e84eaa685879b6bdcc717e4 ] Protect against potential stack overflow that might happen when bpf2bpf calls get combined with tailcalls. Limit the caller's stack depth for such case down to 256 so that the worst case scenario would result in 8k stack size (32 which is tailcall limit * 256 = 8k). Suggested-by: Alexei Starovoitov Signed-off-by: Maciej Fijalkowski Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin

soc: mediatek: cmdq: add clear option in cmdq_pkt_wfe api

2020-10-29T09:08:15+00:00

[ Upstream commit 23c22299cd290409c6b78f57c42b64f8dfb6dd92 ] Add clear parameter to let client decide if event should be clear to 0 after GCE receive it. Signed-off-by: Dennis YC Hsieh Acked-by: Chun-Kuang Hu Link: https://lore.kernel.org/r/1594136714-11650-9-git-send-email-dennis-yc.hsieh@mediatek.com [mb: fix commit message] Signed-off-by: Matthias Brugger Signed-off-by: Sasha Levin