<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-dev/drivers/misc/habanalabs/common, branch master</title>
<subtitle>Linux kernel development work - see feature branches</subtitle>
<id>https://git.zx2c4.com/linux-dev/atom/drivers/misc/habanalabs/common?h=master</id>
<link rel='self' href='https://git.zx2c4.com/linux-dev/atom/drivers/misc/habanalabs/common?h=master'/>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/'/>
<updated>2022-09-20T12:52:27Z</updated>
<entry>
<title>habanalabs: eliminate aggregate use warning</title>
<updated>2022-09-20T12:52:27Z</updated>
<author>
<name>Oded Gabbay</name>
<email>ogabbay@kernel.org</email>
</author>
<published>2022-09-19T21:08:40Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=259cee1c2422bcff7ba6bb4e8179faadb52ebdee'/>
<id>urn:sha1:259cee1c2422bcff7ba6bb4e8179faadb52ebdee</id>
<content type='text'>
When doing sizeof() and giving as argument a dereference of
a pointer-to-a-pointer object, clang will issue a warning.

Eliminate the warning by passing struct &lt;name&gt;*

Signed-off-by: Oded Gabbay &lt;ogabbay@kernel.org&gt;
</content>
</entry>
<entry>
<title>habanalabs: remove some f/w descriptor validations</title>
<updated>2022-09-20T12:46:45Z</updated>
<author>
<name>farah kassabri</name>
<email>fkassabri@habana.ai</email>
</author>
<published>2022-08-30T10:01:03Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=6b9b9e244fdd0d6c5ee21b7b9d74282d9e43733a'/>
<id>urn:sha1:6b9b9e244fdd0d6c5ee21b7b9d74282d9e43733a</id>
<content type='text'>
To be forward-backward compatible with the firmware in the initial
communication during preboot, we need to remove the validation of the
header size. This will allow us to add more fields to the
lkd_fw_comms_desc structure.

Instead of the validation of the header size, we just print warning
when some mismatch in descriptor has been revealed, and we calculate
the CRC base on descriptor size reported by the firmware instead of
calculating it ourselves.

Signed-off-by: farah kassabri &lt;fkassabri@habana.ai&gt;
Reviewed-by: Oded Gabbay &lt;ogabbay@kernel.org&gt;
Signed-off-by: Oded Gabbay &lt;ogabbay@kernel.org&gt;
</content>
</entry>
<entry>
<title>habanalabs: failure to open device due to reset is debug level</title>
<updated>2022-09-19T12:09:04Z</updated>
<author>
<name>Oded Gabbay</name>
<email>ogabbay@kernel.org</email>
</author>
<published>2022-09-19T08:30:03Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=4f3ce5e0d0f85d6be0a2bc3a2aa75ba3b649c7c6'/>
<id>urn:sha1:4f3ce5e0d0f85d6be0a2bc3a2aa75ba3b649c7c6</id>
<content type='text'>
If the user wants to open the device, and the device is currently in
reset, the user will get an error from the open().

We don't need to display an error in the dmesg for that as it is
not a real error and we can spam the kernel log with this message.

Signed-off-by: Oded Gabbay &lt;ogabbay@kernel.org&gt;
</content>
</entry>
<entry>
<title>habanalabs/gaudi2: add secured attestation info uapi</title>
<updated>2022-09-19T12:08:40Z</updated>
<author>
<name>Dani Liberman</name>
<email>dliberman@habana.ai</email>
</author>
<published>2022-08-01T12:23:44Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=0c88760f8f5e13e32f624a1da71144b240b05125'/>
<id>urn:sha1:0c88760f8f5e13e32f624a1da71144b240b05125</id>
<content type='text'>
User will provide a nonce via the ioctl, and will retrieve
secured attestation data of the boot, generated using given
nonce.

Signed-off-by: Dani Liberman &lt;dliberman@habana.ai&gt;
Reviewed-by: Oded Gabbay &lt;ogabbay@kernel.org&gt;
Signed-off-by: Oded Gabbay &lt;ogabbay@kernel.org&gt;
</content>
</entry>
<entry>
<title>habanalabs: rename error info structure</title>
<updated>2022-09-19T12:08:39Z</updated>
<author>
<name>Dani Liberman</name>
<email>dliberman@habana.ai</email>
</author>
<published>2022-09-07T13:15:39Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=97a78e3d8e176de80323b7a01cd6b26f0b6dcdc1'/>
<id>urn:sha1:97a78e3d8e176de80323b7a01cd6b26f0b6dcdc1</id>
<content type='text'>
As a preparation for adding more errors to it,
change to more suitable name.

Signed-off-by: Dani Liberman &lt;dliberman@habana.ai&gt;
Reviewed-by: Oded Gabbay &lt;ogabbay@kernel.org&gt;
Signed-off-by: Oded Gabbay &lt;ogabbay@kernel.org&gt;
</content>
</entry>
<entry>
<title>habanalabs: MMU invalidation h/w is per device</title>
<updated>2022-09-19T12:08:39Z</updated>
<author>
<name>Oded Gabbay</name>
<email>ogabbay@kernel.org</email>
</author>
<published>2022-09-05T14:14:45Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=82736b063fde67ea2a9b16ef5acf3d5db03e2deb'/>
<id>urn:sha1:82736b063fde67ea2a9b16ef5acf3d5db03e2deb</id>
<content type='text'>
The code used the mmu mutex to protect access to the context's page
tables and invalidation of the MMU cache. Because pgt are per
context, the mmu mutex was a member of the context object.

The problem is that the device has a single MMU invalidation h/w
(per MMU). Therefore, the mmu mutex should not be a property of the
context but a property of the device.

Signed-off-by: Oded Gabbay &lt;ogabbay@kernel.org&gt;
</content>
</entry>
<entry>
<title>habanalabs: fix resetting the DRAM BAR</title>
<updated>2022-09-19T12:08:38Z</updated>
<author>
<name>Ohad Sharabi</name>
<email>osharabi@habana.ai</email>
</author>
<published>2022-09-01T13:37:08Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=76925f55c9ba46faaf4054a8192dc5814bc2e0ab'/>
<id>urn:sha1:76925f55c9ba46faaf4054a8192dc5814bc2e0ab</id>
<content type='text'>
Current code does not takes into account the new DRAM region base
and so calculated address is wrong and can lead to crush.

Signed-off-by: Ohad Sharabi &lt;osharabi@habana.ai&gt;
Reviewed-by: Oded Gabbay &lt;ogabbay@kernel.org&gt;
Signed-off-by: Oded Gabbay &lt;ogabbay@kernel.org&gt;
</content>
</entry>
<entry>
<title>habanalabs: add support for new cpucp return codes</title>
<updated>2022-09-19T12:08:38Z</updated>
<author>
<name>Ofir Bitton</name>
<email>obitton@habana.ai</email>
</author>
<published>2022-08-23T13:58:38Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=0626fa1a4d311b55b5f20a90380915f1bc135607'/>
<id>urn:sha1:0626fa1a4d311b55b5f20a90380915f1bc135607</id>
<content type='text'>
Firmware now responds with a more detailed cpucp return codes.
Driver can now distinguish between error and debug return codes.

Signed-off-by: Ofir Bitton &lt;obitton@habana.ai&gt;
Reviewed-by: Oded Gabbay &lt;ogabbay@kernel.org&gt;
Signed-off-by: Oded Gabbay &lt;ogabbay@kernel.org&gt;
</content>
</entry>
<entry>
<title>habanalabs/gaudi2: read F/W security indication after hard reset</title>
<updated>2022-09-19T12:08:38Z</updated>
<author>
<name>Tomer Tayar</name>
<email>ttayar@habana.ai</email>
</author>
<published>2022-09-01T11:12:56Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=a0fc8688c003172455f99b6b7e185b167ed964a0'/>
<id>urn:sha1:a0fc8688c003172455f99b6b7e185b167ed964a0</id>
<content type='text'>
F/W security status might change after every reset.

Add the reading of the preboot status to the hard reset sequence, which
among others reads this security indication.

As this preboot status reading includes the waiting for the preboot to
be ready, it can be removed from the CPU init which is done in a later
stage.

Signed-off-by: Tomer Tayar &lt;ttayar@habana.ai&gt;
Reviewed-by: Oded Gabbay &lt;ogabbay@kernel.org&gt;
Signed-off-by: Oded Gabbay &lt;ogabbay@kernel.org&gt;
</content>
</entry>
<entry>
<title>habanalabs: fix possible hole in device va</title>
<updated>2022-09-19T12:08:38Z</updated>
<author>
<name>farah kassabri</name>
<email>fkassabri@habana.ai</email>
</author>
<published>2022-08-23T11:32:42Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=62adba0a55a7dc522f179b8ff8e0b3b7250c440f'/>
<id>urn:sha1:62adba0a55a7dc522f179b8ff8e0b3b7250c440f</id>
<content type='text'>
cb_map_mem() uses gen_pool_alloc() to get virtual address for
mapping a CB.
The mapping is done in chunks of page size, so if the CB size is
larger, it is possible that the allocated virtual addresses won't
be consecutive.
User retrieves this device VA which returns the virtual address
in the first va_block. If there is a "hole" in the virtual addresses,
user can configure a HW block with a bad device VA.

Signed-off-by: farah kassabri &lt;fkassabri@habana.ai&gt;
Reviewed-by: Oded Gabbay &lt;ogabbay@kernel.org&gt;
Signed-off-by: Oded Gabbay &lt;ogabbay@kernel.org&gt;
</content>
</entry>
</feed>
