seeing an odd bug where we fail to correctly return an error from
.get_tree():
https://syzkaller.appspot.com/bug?extid=c0360e8367d6d8d04a66
we need to be able to distinguish between accidently returning a
positive error (as implied by the log) and no error.
Cc: David Howells <dhowells@redhat.com>
Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev>
Journal replay, in the slowpath where we insert keys in journal order,
was inserting keys in the wrong order; keys from early repair come last.
Reported-by: syzbot+2c4fcb257ce2b6a29d0e@syzkaller.appspotmail.com
Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev>
We weren't always so strict about trans->locked state - but now we are,
and new assertions are shaking some bugs out.
Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev>
Comparing the wrong bpos - this was missed because normally
bucket_gens_init() runs on brand new filesystems, but this bug caused it
to overwrite bucket_gens keys with 0s when upgrading ancient
filesystems.
Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev>
On testing on an old mangled filesystem, we missed a case.
Fixes: bd864bc2d9 ("bcachefs: Fix bch2_trigger_alloc when upgrading from old versions")
Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev>
bcachefs_effective.* xattrs show the options inherited from parent
directories (as well as explicitly set); this namespace is not for
setting bcachefs options.
Change the .set() handler to a noop so that if e.g. rsync is copying
xattrs it'll do the right thing, and only copy xattrs in the bcachefs.*
namespace. We don't want to return an error, because that will cause
rsync to bail out or get spammy.
Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev>
data_update_init() does a bunch of complicated stuff to decide how many
replicas to add, since we only want to increase an extent's durability
on an explicit rereplicate, but extent pointers may be on devices with
different durability settings.
There was a corner case when evacuating a device that had been set to
durability=0 after data had been written to it, and extents on that
device had already been rereplicated - then evacuate only needs to drop
pointers on that device, not move them.
So the assert for !m->op.nr_replicas was spurious; this was a perfectly
legitimate case that needed to be handled.
Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev>
USB4 specification defines the metadata needed to perform software
margining, as well as the necessary steps which include waiting for
dwell time.
- Add dwell_time attribute to set the wait time while performing
margining and checking for link errors.
- Add error_counter attribute to configure error counter prior to
margining test.
- Add voltage_time_offset attribute to set the voltage or time offset
steps before performing the software margining test.
- Perform software margining test for dwell duration, break if there are
link errors, stop the clocks and provide results.
Below is a minimalistic example how this can be used. Note these values
are just examples. The exact values in practice depend on host specific
capabilities and the type of measurement to be performed.
# cd /sys/kernel/debug/thunderbolt/ROUTER/portX/margining/
# echo software > mode
# echo 400 > dwell_time
# echo 1 > run
As usual the results attribute contains the results of a succesfull run.
Signed-off-by: R Kannappan <r.kannappan@intel.com>
Co-developed-by: Rene Sapiens <rene.sapiens@intel.com>
Signed-off-by: Rene Sapiens <rene.sapiens@intel.com>
Co-developed-by: Aapo Vienamo <aapo.vienamo@linux.intel.com>
Signed-off-by: Aapo Vienamo <aapo.vienamo@linux.intel.com>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Add optional extended voltage offset range support for software and
hardware margining as defined by the USB4 specification.
If supported, it can be enabled like below:
# cd /sys/kernel/debug/thunderbolt/ROUTER/portX/margining/
# echo Y > optional_voltage_offset
Signed-off-by: Rene Sapiens <rene.sapiens@intel.com>
Co-developed-by: R Kannappan <r.kannappan@intel.com>
Signed-off-by: R Kannappan <r.kannappan@intel.com>
Co-developed-by: Aapo Vienamo <aapo.vienamo@linux.intel.com>
Signed-off-by: Aapo Vienamo <aapo.vienamo@linux.intel.com>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Consolidate the hardware and software margining parameters into a single
structure to reduce the number of parameters passed to the margining
functions.
Signed-off-by: Rene Sapiens <rene.sapiens@intel.com>
Co-developed-by: Aapo Vienamo <aapo.vienamo@linux.intel.com>
Signed-off-by: Aapo Vienamo <aapo.vienamo@linux.intel.com>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Synchronize the operation completion by reading back the software
margining operation completion metadata into margining->results.
Signed-off-by: Aapo Vienamo <aapo.vienamo@linux.intel.com>
Co-developed-by: R Kannappan <r.kannappan@intel.com>
Signed-off-by: R Kannappan <r.kannappan@intel.com>
Co-developed-by: Rene Sapiens <rene.sapiens@intel.com>
Signed-off-by: Rene Sapiens <rene.sapiens@intel.com>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Directly call into dma-iommu just like we have been doing for dma-direct
for a while. This avoids the indirect call overhead for IOMMU ops and
removes the need to have DMA ops entirely for many common configurations.
Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
Signed-off-by: Leon Romanovsky <leon@kernel.org>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Acked-by: Robin Murphy <robin.murphy@arm.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
Almost all instances of the dma_map_ops ->map_page()/map_sg() methods
implement ->unmap_page()/unmap_sg() too. The once instance which doesn't
dma_dummy_ops which is used to fail the DMA mapping and thus there won't
be any calls to ->unmap_page()/unmap_sg().
Remove the checks for ->unmap_page()/unmap_sg() and call them directly to
create an interface that is symmetrical to ->map_page()/map_sg().
Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
Signed-off-by: Leon Romanovsky <leon@kernel.org>
Reviewed-by: Robin Murphy <robin.murphy@arm.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
Commit 791ab8b2e3 ("arm64: Ignore any DMA offsets in the
max_zone_phys() calculation") made arm64 DMA/DMA32 zones span the entire
RAM when RAM starts above 32-bits. This breaks hardware with DMA area
that start above 32-bits. But the commit log says that "we haven't
noticed any such hardware". It turns out that such hardware does exist.
One such platform has RAM starting at 32GB with an internal bus that has
the following DMA limits:
#address-cells = <2>;
#size-cells = <2>;
dma-ranges = <0x00 0xc0000000 0x08 0x00000000 0x00 0x40000000>;
That is, devices under this bus see 1GB of DMA range between 3GB-4GB in
their address space. This range is mapped to CPU memory at 32GB-33GB.
With current code DMA allocations for devices under this bus are not
limited to DMA area, leading to run-time allocation failure.
This commit reinstates DMA zone at the bottom of RAM. The result is DMA
zone that properly reflects the hardware constraints as follows:
[ 0.000000] Zone ranges:
[ 0.000000] DMA [mem 0x0000000800000000-0x000000083fffffff]
[ 0.000000] DMA32 empty
[ 0.000000] Normal [mem 0x0000000840000000-0x0000000bffffffff]
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
[baruch: split off the original patch]
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
Reviewed-by: Petr Tesarik <ptesarik@suse.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
The hardware DMA limit might not be power of 2. When RAM range starts
above 0, say 4GB, DMA limit of 30 bits should end at 5GB. A single high
bit can not encode this limit.
Use a plain address for the DMA zone limit instead.
Since the DMA zone can now potentially span beyond 4GB physical limit of
DMA32, make sure to use DMA zone for GFP_DMA32 allocations in that case.
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Co-developed-by: Baruch Siach <baruch@tkos.co.il>
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
Reviewed-by: Petr Tesarik <ptesarik@suse.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
In dma_common_find_pages(), area->flags are compared directly with
VM_DMA_COHERENT. This works because VM_DMA_COHERENT is the only set
flag.
During development of a new feature (ASI [1]), a new VM flag is
introduced, and that flag can be injected into VM_DMA_COHERENT mappings
(among others). The presence of that flag caused
dma_common_find_pages() to return NULL for VM_DMA_COHERENT addresses,
leading to a lot of problems ending in crashing during boot. It took a
bit of time to figure this problem out.
It was a mistake to inject a VM flag to begin with, but it took a
significant amount of debugging to figure out the problem. Most users of
area->flags use bitmasking rather than equivalency to check for flags.
Update dma_common_find_pages() and dma_common_free_remap() to do the
same, which would have avoided the boot crashing. Instead, add a warning
in dma_common_find_pages() if any extra VM flags are set to catch such
problems more easily during development.
No functional change intended.
[1]https://lore.kernel.org/lkml/20240712-asi-rfc-24-v1-0-144b319a40d8@google.com/
Signed-off-by: Yosry Ahmed <yosryahmed@google.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
Add temperature device in i2c0 and i2c2.
Signed-off-by: Peter Yin <peteryin.openbmc@gmail.com>
Link: https://lore.kernel.org/r/20240801160136.1281291-9-peteryin.openbmc@gmail.com
[andrew: Fixed 'deivce' typo in commit message]
Signed-off-by: Andrew Jeffery <andrew@codeconstruct.com.au>
Signed-off-by: Joel Stanley <joel@jms.id.au>
Add power-chassis-control and power-chassis-power for phosphor-power.
Signed-off-by: Peter Yin <peteryin.openbmc@gmail.com>
Link: https://lore.kernel.org/r/20240801160136.1281291-4-peteryin.openbmc@gmail.com
Signed-off-by: Andrew Jeffery <andrew@codeconstruct.com.au>
Signed-off-by: Joel Stanley <joel@jms.id.au>
These are not specified in the binding and produce warnings such as
the following:
arch/arm/boot/dts/aspeed/aspeed-g6.dtsi:254.27-262.5: Warning
(avoid_unnecessary_addr_size): /ahb/ethernet@1e670000: unnecessary
#address-cells/#size-cells without "ranges", "dma-ranges" or child
"reg" property
arch/arm/boot/dts/aspeed/aspeed-g6.dtsi:264.27-272.5: Warning
(avoid_unnecessary_addr_size): /ahb/ethernet@1e690000: unnecessary
#address-cells/#size-cells without "ranges", "dma-ranges" or child
"reg" property
arch/arm/boot/dts/aspeed/aspeed-ast2600-evb-a1.dtb: ethernet@1e660000:
Unevaluated properties are not allowed ('#address-cells', '#size-cells'
were unexpected)
Link: https://lore.kernel.org/r/20240802-dt-warnings-bmc-dts-cleanups-v1-7-1cb1378e5fcd@codeconstruct.com.au
Signed-off-by: Andrew Jeffery <andrew@codeconstruct.com.au>
Signed-off-by: Joel Stanley <joel@jms.id.au>
Many platforms were specifying the `aspeed,external-nodes` property
required by the AST2500 pinctrl. However, its been specified in the
pinctrl node directly in aspeed-g5.dtsi for quite a long time now.
Remove the unnecessary override from all relevant platform dts files.
Link: https://lore.kernel.org/r/20240802-dt-warnings-bmc-dts-cleanups-v1-5-1cb1378e5fcd@codeconstruct.com.au
Signed-off-by: Andrew Jeffery <andrew@codeconstruct.com.au>
Signed-off-by: Joel Stanley <joel@jms.id.au>
There's no binding defined for the device, so remove it from the
devicetrees until someone has the motivation to write one.
Squash warnings such as:
arch/arm/boot/dts/aspeed/aspeed-ast2500-evb.dtb:
/ahb/apb@1e6e0000/xdma@1e6e7000: failed to match any schema with
compatible: ['aspeed,ast2500-xdma']
Link: https://lore.kernel.org/r/20240802-dt-warnings-bmc-dts-cleanups-v1-4-1cb1378e5fcd@codeconstruct.com.au
Signed-off-by: Andrew Jeffery <andrew@codeconstruct.com.au>
Signed-off-by: Joel Stanley <joel@jms.id.au>
The ASPEED CVIC binding documents `aspeed,cvic` as the required generic
compatible, but the devicetrees contained `aspeed-cvic`. Update the
devictrees to use `aspeed,cvic` as documented and as required by
the driver implementation. Presumably the bug was the result of some
incoherent thoughts while removing the SoC name at the time of
writing.
Link: https://lore.kernel.org/r/20240802-dt-warnings-bmc-dts-cleanups-v1-2-1cb1378e5fcd@codeconstruct.com.au
Signed-off-by: Andrew Jeffery <andrew@codeconstruct.com.au>
Signed-off-by: Joel Stanley <joel@jms.id.au>
Squash schema warnings such as:
arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-galaxy100.dtb:
copro-interrupt-controller@1e6c2000: $nodename:0:
'copro-interrupt-controller@1e6c2000' does not match
'^interrupt-controller(@[0-9a-f,]+)*$'
Link: https://lore.kernel.org/r/20240802-dt-warnings-bmc-dts-cleanups-v1-1-1cb1378e5fcd@codeconstruct.com.au
Signed-off-by: Andrew Jeffery <andrew@codeconstruct.com.au>
Signed-off-by: Joel Stanley <joel@jms.id.au>
Add LED nodes as the gpio-leds devices. They are led-bmc-ready,
led-sw-heartbeat, led-identify, led-fault, led-fan-fault, led-psu-fault
Signed-off-by: Chanh Nguyen <chanh@os.amperecomputing.com>
Link: https://lore.kernel.org/r/20240806071806.1666550-6-chanh@os.amperecomputing.com
Signed-off-by: Andrew Jeffery <andrew@codeconstruct.com.au>
Signed-off-by: Joel Stanley <joel@jms.id.au>
Enable the BMC I2C10.
Enable the BMC I2C15 and add the GPIO Expander as a child node.
Signed-off-by: Chanh Nguyen <chanh@os.amperecomputing.com>
Link: https://lore.kernel.org/r/20240806071806.1666550-5-chanh@os.amperecomputing.com
Signed-off-by: Andrew Jeffery <andrew@codeconstruct.com.au>
Signed-off-by: Joel Stanley <joel@jms.id.au>
Define the I2C alias ports for the riser cards.
Add the i2c muxes to switch to the i2c alias ports and
the eeprom nodes to read the FRU contents on riser cards.
Signed-off-by: Chanh Nguyen <chanh@os.amperecomputing.com>
Link: https://lore.kernel.org/r/20240806071806.1666550-4-chanh@os.amperecomputing.com
Signed-off-by: Andrew Jeffery <andrew@codeconstruct.com.au>
Signed-off-by: Joel Stanley <joel@jms.id.au>
Add the I2C alias ports to read temperature sensors via channels
of the I2C muxes.
Signed-off-by: Chanh Nguyen <chanh@os.amperecomputing.com>
Link: https://lore.kernel.org/r/20240806071806.1666550-3-chanh@os.amperecomputing.com
Signed-off-by: Andrew Jeffery <andrew@codeconstruct.com.au>
Signed-off-by: Joel Stanley <joel@jms.id.au>
Define I2C alias ports from I2C Switch 0x70 at BMC I2C5.
Add the tmp421 sensors via the I2C alias ports as OCP device
temperature sensors.
Signed-off-by: Chanh Nguyen <chanh@os.amperecomputing.com>
Link: https://lore.kernel.org/r/20240806071806.1666550-2-chanh@os.amperecomputing.com
Signed-off-by: Andrew Jeffery <andrew@codeconstruct.com.au>
Signed-off-by: Joel Stanley <joel@jms.id.au>
Add linux device tree entry for Meta(Facebook) Catalina compute-tray
BMC using AT2600 SoC.
Signed-off-by: Potin Lai <potin.lai.pt@gmail.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20240805-potin-catalina-dts-v7-2-286bfd2ab93b@gmail.com
Signed-off-by: Andrew Jeffery <andrew@codeconstruct.com.au>
Signed-off-by: Joel Stanley <joel@jms.id.au>
Document the new compatibles used on Meta Catalina.
Signed-off-by: Potin Lai <potin.lai.pt@gmail.com>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20240805-potin-catalina-dts-v7-1-286bfd2ab93b@gmail.com
Signed-off-by: Andrew Jeffery <andrew@codeconstruct.com.au>
Signed-off-by: Joel Stanley <joel@jms.id.au>
