[PATCH v2 1/1] dt-bindings: remoteproc: imx_rproc: add minItems for power-domain

[Frank Li]

"fsl,imx8qxp-cm4" and "fsl,imx8qm-cm4" need minimum 2 power domains. Keep
the same restriction for other compatible string.

Signed-off-by: Frank Li 
---

Notes:
Change from v1 to v2
- set minitem to 2 at top
- Add imx8qm compatible string also
- use not logic to handle difference compatible string restriction
- update commit message.

pass dt_binding_check.

make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- -j8  dt_binding_check 
DT_SCHEMA_FILES=fsl,imx-rproc.yaml
  SCHEMA  Documentation/devicetree/bindings/processed-schema.json
  CHKDT   Documentation/devicetree/bindings
  LINTDocumentation/devicetree/bindings
  DTEX
Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.example.dts
  DTC_CHK 
Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.example.dtb

 .../bindings/remoteproc/fsl,imx-rproc.yaml | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml 
b/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml
index df36e29d974ca..da108a39df435 100644
--- a/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml
+++ b/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml
@@ -59,6 +59,7 @@ properties:
 maxItems: 32
 
   power-domains:
+minItems: 2
 maxItems: 8
 
   fsl,auto-boot:
@@ -99,6 +100,19 @@ allOf:
   properties:
 fsl,iomuxc-gpr: false
 
+  - if:
+  properties:
+compatible:
+  not:
+contains:
+  enum:
+- fsl,imx8qxp-cm4
+- fsl,imx8qm-cm4
+then:
+  properties:
+power-domains:
+  minItems: 8
+
 additionalProperties: false
 
 examples:
-- 
2.34.1

[Bug 2065579] Re: [UBUNTU 22.04] OS guest boot issues on 9p filesystem

[Frank Heimes]

** Changed in: ubuntu-z-systems
   Status: New => Fix Released

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2065579

Title:
  [UBUNTU 22.04] OS guest boot issues on 9p filesystem

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/2065579/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Re: [FFmpeg-devel] [PATCH v2 2/2] lavc/vvc: Prevent overflow in chroma QP derivation

[Frank Plowman]

Hi,

Thanks for your review.

On 05/06/2024 14:50, Nuo Mi wrote:
> Hi Frank,
> Thank you for the patch
> 
> On Wed, Jun 5, 2024 at 5:24 PM Frank Plowman  wrote:
> 
>> On the top of p. 112 in VVC (09/2023):
>>
>> It is a requirement of bitstream conformance that the values of
>> qpInVal[ i ][ j ] and qpOutVal[ i ][ j ] shall be in the range
>> of −QpBdOffset to 63, inclusive for i in the range of 0 to
>>
> Then, why do we not check −QpBdOffset?

sps_delta_qp_in_val_minus1 is unsigned, therefore we would only need to
check the first elements qp{In,Out}Val[i][0], both of which are set to
sps_qp_table_start_minus26[i] + 26.

sps_qp_table_start_minus26[i] is already constrained to the range
[-26-QpBdOffset..36] (see VVC (09/2023) p. 111 and
libavcodec/cbs_h266_syntax_template.c:1387).

I don't get why the standard reiterates the constraint here, it seems
redundant.

> 
>> numQpTables − 1, inclusive, and j in the range of 0 to
>> sps_num_points_in_qp_table_minus1[ i ] + 1, inclusive.
>>
>> Signed-off-by: Frank Plowman 
>> ---
>>  libavcodec/vvc/ps.c | 7 ++-
>>  1 file changed, 6 insertions(+), 1 deletion(-)
>>
>> diff --git a/libavcodec/vvc/ps.c b/libavcodec/vvc/ps.c
>> index bfc3c121fd..c4f64d5da7 100644
>> --- a/libavcodec/vvc/ps.c
>> +++ b/libavcodec/vvc/ps.c
>> @@ -101,9 +101,14 @@ static int sps_chroma_qp_table(VVCSPS *sps)
>>
>>  qp_out[0] = qp_in[0] = r->sps_qp_table_start_minus26[i] + 26;
>>  for (int j = 0; j < num_points_in_qp_table; j++ ) {
>> +const uint8_t delta_qp_out =
>> (r->sps_delta_qp_in_val_minus1[i][j] ^ r->sps_delta_qp_diff_val[i][j]);
>>  delta_qp_in[j] = r->sps_delta_qp_in_val_minus1[i][j] + 1;
>> +if (qp_in[j] + delta_qp_in[j] > 63)
>> +return AVERROR(EINVAL);
>>  qp_in[j+1] = qp_in[j] + delta_qp_in[j];
>> -qp_out[j+1] = qp_out[j] +
>> (r->sps_delta_qp_in_val_minus1[i][j] ^ r->sps_delta_qp_diff_val[i][j]);
>> +if (qp_out[j] + delta_qp_out > 63)
>> +return AVERROR(EINVAL);
>> +qp_out[j+1] = qp_out[j] + delta_qp_out;
>>
> Instead of changing so many lines, we can  add 2 lines here
> if (qp_in[j+1] < 63 ||  qp_out[j+1] < 63)
> return AVERROR(EINVAL);

v3 sent with this tweak & squashing the other patch.

> 
>>  }
>>  sps->chroma_qp_table[i][qp_in[0] + off] = qp_out[0];
>>  for (int k = qp_in[0] - 1 + off; k >= 0; k--)
>> --
>> 2.45.1
>>

Cheers,
-- 
Frank
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH v3] lavc/vvc: Prevent overflow in chroma QP derivation

[Frank Plowman]

On the top of p. 112 in VVC (09/2023):

It is a requirement of bitstream conformance that the values of
qpInVal[ i ][ j ] and qpOutVal[ i ][ j ] shall be in the range
of −QpBdOffset to 63, inclusive for i in the range of 0 to
numQpTables − 1, inclusive, and j in the range of 0 to
sps_num_points_in_qp_table_minus1[ i ] + 1, inclusive.

Additionally, don't discard the return code from sps_chroma_qp_table.

Signed-off-by: Frank Plowman 
---
Changes since v2:
* Squash discarded return code patch and QP overflow patch.
* Combine QpIn and QpOut validation into a single if statement.

 libavcodec/vvc/ps.c | 12 +---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/libavcodec/vvc/ps.c b/libavcodec/vvc/ps.c
index 1b23675c98..ea5d0e9959 100644
--- a/libavcodec/vvc/ps.c
+++ b/libavcodec/vvc/ps.c
@@ -101,9 +101,12 @@ static int sps_chroma_qp_table(VVCSPS *sps)
 
 qp_out[0] = qp_in[0] = r->sps_qp_table_start_minus26[i] + 26;
 for (int j = 0; j < num_points_in_qp_table; j++ ) {
+const uint8_t delta_qp_out = (r->sps_delta_qp_in_val_minus1[i][j] 
^ r->sps_delta_qp_diff_val[i][j]);
 delta_qp_in[j] = r->sps_delta_qp_in_val_minus1[i][j] + 1;
+if (qp_in[j] + delta_qp_in[j] > 63 || qp_out[j] + delta_qp_out > 
63)
+return AVERROR(EINVAL);
 qp_in[j+1] = qp_in[j] + delta_qp_in[j];
-qp_out[j+1] = qp_out[j] + (r->sps_delta_qp_in_val_minus1[i][j] ^ 
r->sps_delta_qp_diff_val[i][j]);
+qp_out[j+1] = qp_out[j] + delta_qp_out;
 }
 sps->chroma_qp_table[i][qp_in[0] + off] = qp_out[0];
 for (int k = qp_in[0] - 1 + off; k >= 0; k--)
@@ -186,8 +189,11 @@ static int sps_derive(VVCSPS *sps, void *log_ctx)
 sps_inter(sps);
 sps_partition_constraints(sps);
 sps_ladf(sps);
-if (r->sps_chroma_format_idc != 0)
-sps_chroma_qp_table(sps);
+if (r->sps_chroma_format_idc != 0) {
+ret = sps_chroma_qp_table(sps);
+if (ret < 0)
+return ret;
+}
 
 return 0;
 }
-- 
2.45.1

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[Bug 2068577] Re: [UBUNTU 24.04] Running sosreport causes the system to crash and produce a dump

[Frank Heimes]

Thanks for having reported this issue.

I tried to recreate this on the systems that I have at hand (which is a z13 in 
PS/SM mode and a LinuxONE 3 in DPM mode) and ran sosreport twice on both 
systems in an LPAR, with a default 24.04 install, and after  having 24.04 
upgraded to the latest level (incl. kernel) with:
sudo apt update && sudo apt full-upgrade # and reboot
and in none of the four cases sosreport crashed for me.
Would you please retry (like my colleagues above already mentioned) with the 
latest kernel (means after full-upgrade)? Even if I cannot recreate with the GA 
kernel on my system(s).

So I'm now trying to figure out differences between your setup and mine.

You sosreport package versions is the same than mine: sosreport (version
4.5.6)

Then I though that you may use a filesystem formatted other than ext4, which 
may cause issues, since the last line that you see seems to be:
"Starting 21/74 filesys [Running: block btrfs ebpf filesys]"
but the debuginfo tells you that you are also on ext4 (like me).

Looks like you system is a IBM z16 Model A01, Machine Type 3931 (that I
do not have at hand).

Is this really happening for you on an LPAR or in a zVM guest? (since
dbginfo also incl. zvm data)?

** Changed in: ubuntu-z-systems
 Assignee: (unassigned) => Skipper Bug Screeners (skipper-screen-team)

** Changed in: sosreport (Ubuntu)
 Assignee: Skipper Bug Screeners (skipper-screen-team) => (unassigned)

** Changed in: ubuntu-z-systems
   Importance: Undecided => High

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2068577

Title:
  [UBUNTU 24.04] Running sosreport causes the system to crash and
  produce a dump

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/2068577/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 2068577] Re: [UBUNTU 24.04] Running sosreport causes the system to crash and produce a dump

[Frank Heimes]

** Package changed: linux (Ubuntu) => sosreport (Ubuntu)

** Also affects: linux (Ubuntu)
   Importance: Undecided
   Status: New

** Also affects: ubuntu-z-systems
   Importance: Undecided
   Status: New

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2068577

Title:
  [UBUNTU 24.04] Running sosreport causes the system to crash and
  produce a dump

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/2068577/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[PATCH] drm/amdgpu: tolerate allocating GTT bo with dcc flag

[Min, Frank]

[AMD Official Use Only - AMD Internal Distribution Only]

From: Frank Min 

Do not return failure for allocating GTT bo with dcc flag on gfx12. This will 
improve compatibility for UMD.

Signed-off-by: Frank Min 
Reviewed-by: Christian König 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 5 -
 1 file changed, 5 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
index 9041c63cabb0..58186de61403 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
@@ -409,11 +409,6 @@ int amdgpu_gem_create_ioctl(struct drm_device *dev, void 
*data,
if (args->in.domains & ~AMDGPU_GEM_DOMAIN_MASK)
return -EINVAL;

-   if ((flags & AMDGPU_GEM_CREATE_GFX12_DCC) &&
-   ((amdgpu_ip_version(adev, GC_HWIP, 0) < IP_VERSION(12, 0, 0)) ||
-!(args->in.domains & AMDGPU_GEM_DOMAIN_VRAM)))
-   return -EINVAL;
-
if (!amdgpu_is_tmz(adev) && (flags & AMDGPU_GEM_CREATE_ENCRYPTED)) {
DRM_NOTE_ONCE("Cannot allocate secure buffer since TMZ is 
disabled\n");
return -EINVAL;
--
2.34.1

[PATCH 1/1] dt-bindings: remoteproc: imx_rproc: add minItems for power-domain

[Frank Li]

"fsl,imx8qxp-cm4" just need 2 power domains. Keep the same restriction for
other compatible string.

Signed-off-by: Frank Li 
---

Notes:
pass dt_binding_check.

make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- -j8  dt_binding_check 
DT_SCHEMA_FILES=fsl,imx-rproc.yaml
  SCHEMA  Documentation/devicetree/bindings/processed-schema.json
  CHKDT   Documentation/devicetree/bindings
  LINTDocumentation/devicetree/bindings
  DTEX
Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.example.dts
  DTC_CHK 
Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.example.dtb

 .../bindings/remoteproc/fsl,imx-rproc.yaml   | 16 
 1 file changed, 16 insertions(+)

diff --git a/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml 
b/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml
index df36e29d974ca..60267c1ba94e0 100644
--- a/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml
+++ b/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml
@@ -59,6 +59,7 @@ properties:
 maxItems: 32
 
   power-domains:
+minItems: 1
 maxItems: 8
 
   fsl,auto-boot:
@@ -99,6 +100,21 @@ allOf:
   properties:
 fsl,iomuxc-gpr: false
 
+  - if:
+  properties:
+compatible:
+  contains:
+enum:
+  - fsl,imx8qxp-cm4
+then:
+  properties:
+power-domains:
+  minItems: 2
+else:
+  properties:
+power-domains:
+  minItems: 8
+
 additionalProperties: false
 
 examples:
-- 
2.34.1

Re: [PATCH 16/18] drm/vc4: Use phys addresses for slave DMA config

[Frank Li]

On Fri, May 24, 2024 at 07:27:00PM +0100, Dave Stevenson wrote:
> From: Phil Elwell 
> 
> Slave addresses for DMA are meant to be supplied as physical addresses
> (contrary to what struct snd_dmaengine_dai_dma_data does).

Can you use the same content for patch 14-17?

Frank

> 
> Signed-off-by: Phil Elwell 
> Signed-off-by: Dave Stevenson 
> ---
>  drivers/gpu/drm/vc4/vc4_hdmi.c | 15 ---
>  1 file changed, 4 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
> index d30f8e8e8967..c2afd72bd96e 100644
> --- a/drivers/gpu/drm/vc4/vc4_hdmi.c
> +++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
> @@ -2696,7 +2696,7 @@ static int vc4_hdmi_audio_init(struct vc4_hdmi 
> *vc4_hdmi)
>   struct snd_soc_card *card = _hdmi->audio.card;
>   struct device *dev = _hdmi->pdev->dev;
>   struct platform_device *codec_pdev;
> - const __be32 *addr;
> + struct resource *iomem;
>   int index, len;
>   int ret;
>  
> @@ -2732,22 +2732,15 @@ static int vc4_hdmi_audio_init(struct vc4_hdmi 
> *vc4_hdmi)
>   }
>  
>   /*
> -  * Get the physical address of VC4_HD_MAI_DATA. We need to retrieve
> -  * the bus address specified in the DT, because the physical address
> -  * (the one returned by platform_get_resource()) is not appropriate
> -  * for DMA transfers.
> -  * This VC/MMU should probably be exposed to avoid this kind of hacks.
> +  * Get the physical address of VC4_HD_MAI_DATA.
>*/
>   index = of_property_match_string(dev->of_node, "reg-names", "hd");
>   /* Before BCM2711, we don't have a named register range */
>   if (index < 0)
>   index = 1;
> + iomem = platform_get_resource(vc4_hdmi->pdev, IORESOURCE_MEM, index);
>  
> - addr = of_get_address(dev->of_node, index, NULL, NULL);
> - if (!addr)
> - return -EINVAL;
> -
> - vc4_hdmi->audio.dma_data.addr = be32_to_cpup(addr) + mai_data->offset;
> + vc4_hdmi->audio.dma_data.addr = iomem->start + mai_data->offset;
>   vc4_hdmi->audio.dma_data.addr_width = DMA_SLAVE_BUSWIDTH_4_BYTES;
>   vc4_hdmi->audio.dma_data.maxburst = 2;
>  
> -- 
> 2.34.1
> 

Re: [PATCH 11/18] dmaengine: bcm2835: Use dma_map_resource to map addresses

[Frank Li]

On Fri, May 24, 2024 at 07:26:55PM +0100, Dave Stevenson wrote:
> There is a need to account for dma-ranges and iommus in the
> dma mapping process, and the public API for handling that is
> dma_map_resource.

what's means?

> 
> Add support for mapping addresses to the DMA driver.
> 
> Signed-off-by: Dave Stevenson 
> ---
>  drivers/dma/bcm2835-dma.c | 46 ++-
>  1 file changed, 41 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/dma/bcm2835-dma.c b/drivers/dma/bcm2835-dma.c
> index 9531c0b82071..e48008b06716 100644
> --- a/drivers/dma/bcm2835-dma.c
> +++ b/drivers/dma/bcm2835-dma.c
> @@ -67,6 +67,10 @@ struct bcm2835_cb_entry {
>  
>  struct bcm2835_dma_chan_map {
>   dma_addr_t addr;
> + enum dma_data_direction dir;
> +
> + phys_addr_t slave_addr;
> + unsigned int xfer_size;
>  };
>  
>  struct bcm2835_chan {
> @@ -294,12 +298,44 @@ static int bcm2835_dma_map_slave_addr(struct dma_chan 
> *chan,
>   return 0;
>   }

where umap function? I suppose you should unmap all when terminate chan
or free chan by client driver. 

>  
> - /*
> -  * This path will be updated to handle new clients, but currently should
> -  * never be used.
> -  */
> + if (dev_size != DMA_SLAVE_BUSWIDTH_4_BYTES)
> + return -EIO;
> +
> + /* Reuse current map if possible. */
> + if (dev_addr == map->slave_addr &&
> + dev_size == map->xfer_size &&
> + dev_dir == map->dir)
> + return 0;
> +
> + /* Remove old mapping if present. */
> + if (map->xfer_size) {
> + dev_dbg(chan->device->dev, "chan: unmap %zx@%pap to %pad dir: 
> %s\n",
> + dev_size, _addr, >addr,
> + dev_dir == DMA_TO_DEVICE ? "DMA_TO_DEVICE" : 
> "DMA_FROM_DEVICE");
> + dma_unmap_resource(chan->device->dev, map->addr,
> +map->xfer_size, map->dir, 0);
> + }
> + map->xfer_size = 0;
>  
> - return -EINVAL;
> + /* Create new slave address map. */
> + map->addr = dma_map_resource(chan->device->dev, dev_addr, dev_size,
> +  dev_dir, 0);
> +
> + if (dma_mapping_error(chan->device->dev, map->addr)) {
> + dev_err(chan->device->dev, "chan: failed to map %zx@%pap",
> + dev_size, _addr);
> + return -EIO;
> + }
> +
> + dev_dbg(chan->device->dev, "chan: map %zx@%pap to %pad dir: %s\n",
> + dev_size, _addr, >addr,
> + dev_dir == DMA_TO_DEVICE ? "DMA_TO_DEVICE" : "DMA_FROM_DEVICE");
> +
> + map->slave_addr = dev_addr;
> + map->xfer_size = dev_size;
> + map->dir = dev_dir;
> +
> + return 0;
>  }
>  
>  static void bcm2835_dma_free_cb_chain(struct bcm2835_desc *desc)
> -- 
> 2.34.1
> 

Re: [PATCH 09/18] dmaengine: bcm2835: Add function to handle DMA mapping

[Frank Li]

On Fri, May 24, 2024 at 07:26:53PM +0100, Dave Stevenson wrote:
> The code handling DMA mapping is currently incorrect and
> needs a sequence of fixups.

Can you descript what incorrect here? 

> Move the mapping out into a separate function and structure
> to allow for those fixes to be applied more cleanly.
> 
> Signed-off-by: Dave Stevenson 
> ---
>  drivers/dma/bcm2835-dma.c | 46 ---
>  1 file changed, 38 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/dma/bcm2835-dma.c b/drivers/dma/bcm2835-dma.c
> index aefaa1f01d7f..ef1d95bae84e 100644
> --- a/drivers/dma/bcm2835-dma.c
> +++ b/drivers/dma/bcm2835-dma.c
> @@ -65,6 +65,10 @@ struct bcm2835_cb_entry {
>   dma_addr_t paddr;
>  };
>  
> +struct bcm2835_dma_chan_map {
> + dma_addr_t addr;
> +};
> +
>  struct bcm2835_chan {
>   struct virt_dma_chan vc;
>  
> @@ -74,6 +78,7 @@ struct bcm2835_chan {
>   int ch;
>   struct bcm2835_desc *desc;
>   struct dma_pool *cb_pool;
> + struct bcm2835_dma_chan_map map;

I suppose map should in bcm2835_desc.  if put in chan, how about client
driver create two desc by bcm2835_dma_prep_slave_sg()?

prep_slave_sg()
submit()
prep_savle_sg()
submit()
issue_pending()

Frank

>  
>   void __iomem *chan_base;
>   int irq_number;
> @@ -268,6 +273,19 @@ static inline bool need_dst_incr(enum 
> dma_transfer_direction direction)
>   }
>  
>   return false;
> +};
> +
> +static int bcm2835_dma_map_slave_addr(struct dma_chan *chan,
> +   phys_addr_t dev_addr,
> +   size_t dev_size,
> +   enum dma_data_direction dev_dir)
> +{
> + struct bcm2835_chan *c = to_bcm2835_dma_chan(chan);
> + struct bcm2835_dma_chan_map *map = >map;
> +
> + map->addr = dev_addr;
> +
> + return 0;
>  }
>  
>  static void bcm2835_dma_free_cb_chain(struct bcm2835_desc *desc)
> @@ -734,13 +752,19 @@ static struct dma_async_tx_descriptor 
> *bcm2835_dma_prep_slave_sg(
>   }
>  
>   if (direction == DMA_DEV_TO_MEM) {
> - if (c->cfg.src_addr_width != DMA_SLAVE_BUSWIDTH_4_BYTES)
> + if (bcm2835_dma_map_slave_addr(chan, c->cfg.src_addr,
> +c->cfg.src_addr_width,
> +DMA_TO_DEVICE))
>   return NULL;
> - src = c->cfg.src_addr;
> +
> + src = c->map.addr;
>   } else {
> - if (c->cfg.dst_addr_width != DMA_SLAVE_BUSWIDTH_4_BYTES)
> + if (bcm2835_dma_map_slave_addr(chan, c->cfg.dst_addr,
> +c->cfg.dst_addr_width,
> +DMA_FROM_DEVICE))
>   return NULL;
> - dst = c->cfg.dst_addr;
> +
> + dst = c->map.addr;
>   }
>  
>   /* count frames in sg list */
> @@ -795,14 +819,20 @@ static struct dma_async_tx_descriptor 
> *bcm2835_dma_prep_dma_cyclic(
> __func__, buf_len, period_len);
>  
>   if (direction == DMA_DEV_TO_MEM) {
> - if (c->cfg.src_addr_width != DMA_SLAVE_BUSWIDTH_4_BYTES)
> + if (bcm2835_dma_map_slave_addr(chan, c->cfg.src_addr,
> +c->cfg.src_addr_width,
> +DMA_TO_DEVICE))
>   return NULL;
> - src = c->cfg.src_addr;
> +
> + src = c->map.addr;
>   dst = buf_addr;
>   } else {
> - if (c->cfg.dst_addr_width != DMA_SLAVE_BUSWIDTH_4_BYTES)
> + if (bcm2835_dma_map_slave_addr(chan, c->cfg.dst_addr,
> +c->cfg.dst_addr_width,
> +DMA_FROM_DEVICE))
>   return NULL;
> - dst = c->cfg.dst_addr;
> +
> + dst = c->map.addr;
>   src = buf_addr;
>   }
>  
> -- 
> 2.34.1
> 

Re: [PATCH 08/18] dmaengine: bcm2835: pass dma_chan to generic functions

[Frank Li]

On Fri, May 24, 2024 at 07:26:52PM +0100, Dave Stevenson wrote:
> From: Stefan Wahren 
> 
> In preparation to support more platforms pass the dma_chan to the
> generic functions. This provides access to the DMA device and possible
> platform specific data.

why need this change? you can easy convert between dma_chan and
bcm2835_chan.


> 
> Signed-off-by: Stefan Wahren 
> Signed-off-by: Dave Stevenson 
> ---
>  drivers/dma/bcm2835-dma.c | 24 ++--
>  1 file changed, 14 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/dma/bcm2835-dma.c b/drivers/dma/bcm2835-dma.c
> index e2f9c8692e6b..aefaa1f01d7f 100644
> --- a/drivers/dma/bcm2835-dma.c
> +++ b/drivers/dma/bcm2835-dma.c
> @@ -288,12 +288,13 @@ static void bcm2835_dma_desc_free(struct virt_dma_desc 
> *vd)
>  }
>  
>  static bool
> -bcm2835_dma_create_cb_set_length(struct bcm2835_chan *chan,
> +bcm2835_dma_create_cb_set_length(struct dma_chan *chan,
>struct bcm2835_dma_cb *control_block,
>size_t len, size_t period_len,
>size_t *total_len)
>  {
> - size_t max_len = bcm2835_dma_max_frame_length(chan);
> + struct bcm2835_chan *c = to_bcm2835_dma_chan(chan);
> + size_t max_len = bcm2835_dma_max_frame_length(c);
>  
>   /* set the length taking lite-channel limitations into account */
>   control_block->length = min_t(u32, len, max_len);
> @@ -417,7 +418,7 @@ static struct bcm2835_desc *bcm2835_dma_create_cb_chain(
>   /* set up length in control_block if requested */
>   if (buf_len) {
>   /* calculate length honoring period_length */
> - if (bcm2835_dma_create_cb_set_length(c, control_block,
> + if (bcm2835_dma_create_cb_set_length(chan, 
> control_block,
>len, period_len,
>_len)) {
>   /* add extrainfo bits in info */
> @@ -485,8 +486,9 @@ static void bcm2835_dma_fill_cb_chain_with_sg(
>   }
>  }
>  
> -static void bcm2835_dma_abort(struct bcm2835_chan *c)
> +static void bcm2835_dma_abort(struct dma_chan *chan)
>  {
> + struct bcm2835_chan *c = to_bcm2835_dma_chan(chan);
>   void __iomem *chan_base = c->chan_base;
>   long int timeout = 1;
>  
> @@ -513,8 +515,9 @@ static void bcm2835_dma_abort(struct bcm2835_chan *c)
>   writel(BCM2835_DMA_RESET, chan_base + BCM2835_DMA_CS);
>  }
>  
> -static void bcm2835_dma_start_desc(struct bcm2835_chan *c)
> +static void bcm2835_dma_start_desc(struct dma_chan *chan)
>  {
> + struct bcm2835_chan *c = to_bcm2835_dma_chan(chan);
>   struct virt_dma_desc *vd = vchan_next_desc(>vc);
>   struct bcm2835_desc *d;
>  
> @@ -533,7 +536,8 @@ static void bcm2835_dma_start_desc(struct bcm2835_chan *c)
>  
>  static irqreturn_t bcm2835_dma_callback(int irq, void *data)
>  {
> - struct bcm2835_chan *c = data;
> + struct dma_chan *chan = data;
> + struct bcm2835_chan *c = to_bcm2835_dma_chan(chan);
>   struct bcm2835_desc *d;
>   unsigned long flags;
>  
> @@ -566,7 +570,7 @@ static irqreturn_t bcm2835_dma_callback(int irq, void 
> *data)
>   vchan_cyclic_callback(>vd);
>   } else if (!readl(c->chan_base + BCM2835_DMA_ADDR)) {
>   vchan_cookie_complete(>desc->vd);
> - bcm2835_dma_start_desc(c);
> + bcm2835_dma_start_desc(chan);
>   }
>   }
>  
> @@ -594,7 +598,7 @@ static int bcm2835_dma_alloc_chan_resources(struct 
> dma_chan *chan)
>   }
>  
>   return request_irq(c->irq_number, bcm2835_dma_callback,
> -c->irq_flags, "DMA IRQ", c);
> +c->irq_flags, "DMA IRQ", chan);
>  }
>  
>  static void bcm2835_dma_free_chan_resources(struct dma_chan *chan)
> @@ -682,7 +686,7 @@ static void bcm2835_dma_issue_pending(struct dma_chan 
> *chan)
>  
>   spin_lock_irqsave(>vc.lock, flags);
>   if (vchan_issue_pending(>vc) && !c->desc)
> - bcm2835_dma_start_desc(c);
> + bcm2835_dma_start_desc(chan);
>  
>   spin_unlock_irqrestore(>vc.lock, flags);
>  }
> @@ -846,7 +850,7 @@ static int bcm2835_dma_terminate_all(struct dma_chan 
> *chan)
>   if (c->desc) {
>   vchan_terminate_vdesc(>desc->vd);
>   c->desc = NULL;
> - bcm2835_dma_abort(c);
> + bcm2835_dma_abort(chan);
>   }
>  
>   vchan_get_all_descriptors(>vc, );
> -- 
> 2.34.1
> 

Re: [PATCH 07/18] dmaengine: bcm2385: drop info parameters

[Frank Li]

On Fri, May 24, 2024 at 07:26:51PM +0100, Dave Stevenson wrote:
> From: Stefan Wahren 
> 
> The parameters info and finalextrainfo are platform specific. So drop
> them by generating them within bcm2835_dma_create_cb_chain().

Drop 'info' and 'finalextrainfo' because these can be generated by 
bcm2835_dma_create_cb_chain().

> 
> Signed-off-by: Stefan Wahren 
> Signed-off-by: Dave Stevenson 
> ---
>  drivers/dma/bcm2835-dma.c | 83 +++
>  1 file changed, 40 insertions(+), 43 deletions(-)
> 
> diff --git a/drivers/dma/bcm2835-dma.c b/drivers/dma/bcm2835-dma.c
> index d6c5a2762a46..e2f9c8692e6b 100644
> --- a/drivers/dma/bcm2835-dma.c
> +++ b/drivers/dma/bcm2835-dma.c
> @@ -287,13 +287,11 @@ static void bcm2835_dma_desc_free(struct virt_dma_desc 
> *vd)
>   container_of(vd, struct bcm2835_desc, vd));
>  }
>  
> -static void bcm2835_dma_create_cb_set_length(
> - struct bcm2835_chan *chan,
> - struct bcm2835_dma_cb *control_block,
> - size_t len,
> - size_t period_len,
> - size_t *total_len,
> - u32 finalextrainfo)
> +static bool
> +bcm2835_dma_create_cb_set_length(struct bcm2835_chan *chan,
> +  struct bcm2835_dma_cb *control_block,
> +  size_t len, size_t period_len,
> +  size_t *total_len)

Can you document this function, what's return value means? look like if
need extrainfo?

>  {
>   size_t max_len = bcm2835_dma_max_frame_length(chan);
>  
> @@ -302,7 +300,7 @@ static void bcm2835_dma_create_cb_set_length(
>  
>   /* finished if we have no period_length */
>   if (!period_len)
> - return;
> + return false;
>  
>   /*
>* period_len means: that we need to generate
> @@ -316,7 +314,7 @@ static void bcm2835_dma_create_cb_set_length(
>   if (*total_len + control_block->length < period_len) {
>   /* update number of bytes in this period so far */
>   *total_len += control_block->length;
> - return;
> + return false;
>   }
>  
>   /* calculate the length that remains to reach period_length */
> @@ -325,8 +323,7 @@ static void bcm2835_dma_create_cb_set_length(
>   /* reset total_length for next period */
>   *total_len = 0;
>  
> - /* add extrainfo bits in info */
> - control_block->info |= finalextrainfo;
> + return true;
>  }
>  
>  static inline size_t bcm2835_dma_count_frames_for_sg(
> @@ -352,7 +349,6 @@ static inline size_t bcm2835_dma_count_frames_for_sg(
>   * @chan:   the @dma_chan for which we run this
>   * @direction:  the direction in which we transfer
>   * @cyclic: it is a cyclic transfer
> - * @info:   the default info bits to apply per controlblock
>   * @frames: number of controlblocks to allocate
>   * @src:the src address to assign
>   * @dst:the dst address to assign
> @@ -360,22 +356,24 @@ static inline size_t bcm2835_dma_count_frames_for_sg(
>   * @period_len: the period length when to apply @finalextrainfo
>   *  in addition to the last transfer
>   *  this will also break some control-blocks early
> - * @finalextrainfo: additional bits in last controlblock
> - *  (or when period_len is reached in case of cyclic)
>   * @gfp:the GFP flag to use for allocation
> + * @flags
>   */
>  static struct bcm2835_desc *bcm2835_dma_create_cb_chain(
>   struct dma_chan *chan, enum dma_transfer_direction direction,
> - bool cyclic, u32 info, u32 finalextrainfo, size_t frames,
> - dma_addr_t src, dma_addr_t dst, size_t buf_len,
> - size_t period_len, gfp_t gfp)
> + bool cyclic, size_t frames, dma_addr_t src, dma_addr_t dst,
> + size_t buf_len, size_t period_len, gfp_t gfp, unsigned long flags)
>  {
> + struct bcm2835_dmadev *od = to_bcm2835_dma_dev(chan->device);
>   struct bcm2835_chan *c = to_bcm2835_dma_chan(chan);
>   size_t len = buf_len, total_len;
>   size_t frame;
>   struct bcm2835_desc *d;
>   struct bcm2835_cb_entry *cb_entry;
>   struct bcm2835_dma_cb *control_block;
> + u32 extrainfo = bcm2835_dma_prepare_cb_extra(c, direction, cyclic,
> +  false, flags);
> + bool zero_page = false;
>  
>   if (!frames)
>   return NULL;
> @@ -389,6 +387,14 @@ static struct bcm2835_desc *bcm2835_dma_create_cb_chain(
>   d->dir = direction;
>   d->cyclic = cyclic;
>  
> + switch (direction) {
> + case DMA_MEM_TO_MEM:
> + case DMA_DEV_TO_MEM:
> + break;
> + default:
> + zero_page = src == od->zero_page;
> + }
> +
>   /*
>* Iterate over all frames, create a control block
>* for each frame and link them together.
> @@ -402,7 +408,8 @@ static struct bcm2835_desc *bcm2835_dma_create_cb_chain(
>  
>   /* fill 

Re: [PATCH 06/18] dmaengine: bcm2835: make address increment platform independent

[Frank Li]

On Fri, May 24, 2024 at 07:26:50PM +0100, Dave Stevenson wrote:
> From: Stefan Wahren 
> 
> Actually the criteria to increment source & destination address doesn't
> based on platform specific bits. It's just the DMA transfer direction which
> is translated into the info bits. So introduce two new helper functions
> and get the rid of these platform specifics.
> 

Fix increment source & destination address depend on the platform drvdata.
It should be depend on dma_transfer_direction.

look like it is bug fixes. Can you add fixes tag.

> Signed-off-by: Stefan Wahren 
> Signed-off-by: Dave Stevenson 
> ---
>  drivers/dma/bcm2835-dma.c | 28 ++--
>  1 file changed, 22 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/dma/bcm2835-dma.c b/drivers/dma/bcm2835-dma.c
> index ef452ebb3c15..d6c5a2762a46 100644
> --- a/drivers/dma/bcm2835-dma.c
> +++ b/drivers/dma/bcm2835-dma.c
> @@ -252,6 +252,24 @@ static u32 bcm2835_dma_prepare_cb_extra(struct 
> bcm2835_chan *c,
>   return result;
>  }
>  
> +static inline bool need_src_incr(enum dma_transfer_direction direction)
> +{
> + return direction != DMA_DEV_TO_MEM;
> +}
> +
> +static inline bool need_dst_incr(enum dma_transfer_direction direction)
> +{
> + switch (direction) {
> + case DMA_MEM_TO_MEM:
> + case DMA_DEV_TO_MEM:
> + return true;
> + default:
> + break;
> + }
> +
> + return false;
> +}
> +
>  static void bcm2835_dma_free_cb_chain(struct bcm2835_desc *desc)
>  {
>   size_t i;
> @@ -336,10 +354,8 @@ static inline size_t bcm2835_dma_count_frames_for_sg(
>   * @cyclic: it is a cyclic transfer
>   * @info:   the default info bits to apply per controlblock
>   * @frames: number of controlblocks to allocate
> - * @src:the src address to assign (if the S_INC bit is set
> - *  in @info, then it gets incremented)
> - * @dst:the dst address to assign (if the D_INC bit is set
> - *  in @info, then it gets incremented)
> + * @src:the src address to assign
> + * @dst:the dst address to assign
>   * @buf_len:the full buffer length (may also be 0)
>   * @period_len: the period length when to apply @finalextrainfo
>   *  in addition to the last transfer
> @@ -408,9 +424,9 @@ static struct bcm2835_desc *bcm2835_dma_create_cb_chain(
>   d->cb_list[frame - 1].cb->next = cb_entry->paddr;
>  
>   /* update src and dst and length */
> - if (src && (info & BCM2835_DMA_S_INC))
> + if (src && need_src_incr(direction))
>   src += control_block->length;
> - if (dst && (info & BCM2835_DMA_D_INC))
> + if (dst && need_dst_incr(direction))
>   dst += control_block->length;
>  
>   /* Length of total transfer */
> -- 
> 2.34.1
> 

Re: [PATCH 05/18] dmaengine: bcm2835: move CB final extra info generation into function

[Frank Li]

On Fri, May 24, 2024 at 07:26:49PM +0100, Dave Stevenson wrote:
> From: Stefan Wahren 
> 
> Similar to the info generation, generate the final extra info with a
> separate function. This is necessary to introduce other platforms
> with different info bits.

Each patch commit is independent. 

Introduce common help function to generate the final extra info to reduce
duplicate codes in each DMA operation.


> 
> Signed-off-by: Stefan Wahren 
> Signed-off-by: Dave Stevenson 
> ---
>  drivers/dma/bcm2835-dma.c | 34 --
>  1 file changed, 28 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/dma/bcm2835-dma.c b/drivers/dma/bcm2835-dma.c
> index 7cef7ff89575..ef452ebb3c15 100644
> --- a/drivers/dma/bcm2835-dma.c
> +++ b/drivers/dma/bcm2835-dma.c
> @@ -229,6 +229,29 @@ static u32 bcm2835_dma_prepare_cb_info(struct 
> bcm2835_chan *c,
>   return result;
>  }
>  
> +static u32 bcm2835_dma_prepare_cb_extra(struct bcm2835_chan *c,
> + enum dma_transfer_direction direction,
> + bool cyclic, bool final,
> + unsigned long flags)
> +{
> + u32 result = 0;
> +
> + if (cyclic) {
> + if (flags & DMA_PREP_INTERRUPT)
> + result |= BCM2835_DMA_INT_EN;
> + } else {
> + if (!final)
> + return 0;
> +
> + result |= BCM2835_DMA_INT_EN;
> +
> + if (direction == DMA_MEM_TO_MEM)
> + result |= BCM2835_DMA_WAIT_RESP;
> + }


move if (direction == DMA_MEM_TO_MEM) outof else branch. 
DMA_MEM_TO_MEM is impossible for cyclic. Reduce if level can help
easy to follow up.


if (cyclic)
...
else
...

if (direction == DMA_MEM_TO_MEM)
result |= BCM2835_DMA_WAIT_RESP; 



> +
> + return result;
> +}
> +
>  static void bcm2835_dma_free_cb_chain(struct bcm2835_desc *desc)
>  {
>   size_t i;
> @@ -644,7 +667,8 @@ static struct dma_async_tx_descriptor 
> *bcm2835_dma_prep_dma_memcpy(
>   struct bcm2835_chan *c = to_bcm2835_dma_chan(chan);
>   struct bcm2835_desc *d;
>   u32 info = bcm2835_dma_prepare_cb_info(c, DMA_MEM_TO_MEM, false);
> - u32 extra = BCM2835_DMA_INT_EN | BCM2835_DMA_WAIT_RESP;
> + u32 extra = bcm2835_dma_prepare_cb_extra(c, DMA_MEM_TO_MEM, false,
> +  true, 0);
>   size_t max_len = bcm2835_dma_max_frame_length(c);
>   size_t frames;
>  
> @@ -675,7 +699,7 @@ static struct dma_async_tx_descriptor 
> *bcm2835_dma_prep_slave_sg(
>   struct bcm2835_desc *d;
>   dma_addr_t src = 0, dst = 0;
>   u32 info = bcm2835_dma_prepare_cb_info(c, direction, false);
> - u32 extra = BCM2835_DMA_INT_EN;
> + u32 extra = bcm2835_dma_prepare_cb_extra(c, direction, false, true, 0);
>   size_t frames;
>  
>   if (!is_slave_direction(direction)) {
> @@ -723,7 +747,7 @@ static struct dma_async_tx_descriptor 
> *bcm2835_dma_prep_dma_cyclic(
>   dma_addr_t src, dst;
>   u32 info = bcm2835_dma_prepare_cb_info(c, direction,
>  buf_addr == od->zero_page);
> - u32 extra = 0;
> + u32 extra = bcm2835_dma_prepare_cb_extra(c, direction, true, true, 0);
>   size_t max_len = bcm2835_dma_max_frame_length(c);
>   size_t frames;
>  
> @@ -739,9 +763,7 @@ static struct dma_async_tx_descriptor 
> *bcm2835_dma_prep_dma_cyclic(
>   return NULL;
>   }
>  
> - if (flags & DMA_PREP_INTERRUPT)
> - extra |= BCM2835_DMA_INT_EN;
> - else
> + if (!(flags & DMA_PREP_INTERRUPT))
>   period_len = buf_len;
>  
>   /*
> -- 
> 2.34.1
> 

Re: [PATCH 04/18] dmaengine: bcm2835: move CB info generation into separate function

[Frank Li]

On Fri, May 24, 2024 at 07:26:48PM +0100, Dave Stevenson wrote:
> From: Stefan Wahren 
> 
> Actually the generation of the Control Block info follows some simple
> rules. So handle this with a separate function to avoid open coding
> for every DMA operation. Another advantage is that we can easier
> introduce other platforms with different info bits.

May simple said as:

Introduce common help funtion to prepare Control Block Info to avoid
dupicate code in every DMA operation.
 
> 
> Signed-off-by: Stefan Wahren 
> Signed-off-by: Dave Stevenson 
> ---
>  drivers/dma/bcm2835-dma.c | 50 +--
>  1 file changed, 32 insertions(+), 18 deletions(-)
> 
> diff --git a/drivers/dma/bcm2835-dma.c b/drivers/dma/bcm2835-dma.c
> index 528c4593b45a..7cef7ff89575 100644
> --- a/drivers/dma/bcm2835-dma.c
> +++ b/drivers/dma/bcm2835-dma.c
> @@ -201,6 +201,34 @@ static inline struct bcm2835_desc *to_bcm2835_dma_desc(
>   return container_of(t, struct bcm2835_desc, vd.tx);
>  }
>  
> +static u32 bcm2835_dma_prepare_cb_info(struct bcm2835_chan *c,
> +enum dma_transfer_direction direction,
> +bool zero_page)
> +{
> + u32 result;
> +
> + if (direction == DMA_MEM_TO_MEM)
> + return BCM2835_DMA_D_INC | BCM2835_DMA_S_INC;
> +
> + result = BCM2835_DMA_WAIT_RESP;
> +
> + /* Setup DREQ channel */
> + if (c->dreq != 0)
> + result |= BCM2835_DMA_PER_MAP(c->dreq);
> +
> + if (direction == DMA_DEV_TO_MEM) {
> + result |= BCM2835_DMA_S_DREQ | BCM2835_DMA_D_INC;
> + } else {
> + result |= BCM2835_DMA_D_DREQ | BCM2835_DMA_S_INC;
> +
> + /* non-lite channels can write zeroes w/o accessing memory */
> + if (zero_page && !c->is_lite_channel)
> + result |= BCM2835_DMA_S_IGNORE;
> + }
> +
> + return result;
> +}
> +
>  static void bcm2835_dma_free_cb_chain(struct bcm2835_desc *desc)
>  {
>   size_t i;
> @@ -615,7 +643,7 @@ static struct dma_async_tx_descriptor 
> *bcm2835_dma_prep_dma_memcpy(
>  {
>   struct bcm2835_chan *c = to_bcm2835_dma_chan(chan);
>   struct bcm2835_desc *d;
> - u32 info = BCM2835_DMA_D_INC | BCM2835_DMA_S_INC;
> + u32 info = bcm2835_dma_prepare_cb_info(c, DMA_MEM_TO_MEM, false);
>   u32 extra = BCM2835_DMA_INT_EN | BCM2835_DMA_WAIT_RESP;
>   size_t max_len = bcm2835_dma_max_frame_length(c);
>   size_t frames;
> @@ -646,7 +674,7 @@ static struct dma_async_tx_descriptor 
> *bcm2835_dma_prep_slave_sg(
>   struct bcm2835_chan *c = to_bcm2835_dma_chan(chan);
>   struct bcm2835_desc *d;
>   dma_addr_t src = 0, dst = 0;
> - u32 info = BCM2835_DMA_WAIT_RESP;
> + u32 info = bcm2835_dma_prepare_cb_info(c, direction, false);
>   u32 extra = BCM2835_DMA_INT_EN;
>   size_t frames;
>  
> @@ -656,19 +684,14 @@ static struct dma_async_tx_descriptor 
> *bcm2835_dma_prep_slave_sg(
>   return NULL;
>   }
>  
> - if (c->dreq != 0)
> - info |= BCM2835_DMA_PER_MAP(c->dreq);
> -
>   if (direction == DMA_DEV_TO_MEM) {
>   if (c->cfg.src_addr_width != DMA_SLAVE_BUSWIDTH_4_BYTES)
>   return NULL;
>   src = c->cfg.src_addr;
> - info |= BCM2835_DMA_S_DREQ | BCM2835_DMA_D_INC;
>   } else {
>   if (c->cfg.dst_addr_width != DMA_SLAVE_BUSWIDTH_4_BYTES)
>   return NULL;
>   dst = c->cfg.dst_addr;
> - info |= BCM2835_DMA_D_DREQ | BCM2835_DMA_S_INC;
>   }
>  
>   /* count frames in sg list */
> @@ -698,7 +721,8 @@ static struct dma_async_tx_descriptor 
> *bcm2835_dma_prep_dma_cyclic(
>   struct bcm2835_chan *c = to_bcm2835_dma_chan(chan);
>   struct bcm2835_desc *d;
>   dma_addr_t src, dst;
> - u32 info = BCM2835_DMA_WAIT_RESP;
> + u32 info = bcm2835_dma_prepare_cb_info(c, direction,
> +buf_addr == od->zero_page);
>   u32 extra = 0;
>   size_t max_len = bcm2835_dma_max_frame_length(c);
>   size_t frames;
> @@ -729,26 +753,16 @@ static struct dma_async_tx_descriptor 
> *bcm2835_dma_prep_dma_cyclic(
> "%s: buffer_length (%zd) is not a multiple of 
> period_len (%zd)\n",
> __func__, buf_len, period_len);
>  
> - /* Setup DREQ channel */
> - if (c->dreq != 0)
> - info |= BCM2835_DMA_PER_MAP(c->dreq);
> -
>   if (direction == DMA_DEV_TO_MEM) {
>   if (c->cfg.src_addr_width != DMA_SLAVE_BUSWIDTH_4_BYTES)
>   return NULL;
>   src = c->cfg.src_addr;
>   dst = buf_addr;
> - info |= BCM2835_DMA_S_DREQ | BCM2835_DMA_D_INC;
>   } else {
>   if (c->cfg.dst_addr_width != DMA_SLAVE_BUSWIDTH_4_BYTES)
>   return NULL;
>   dst = c->cfg.dst_addr;
> 

Re: [PATCH 02/18] dmaengine: bcm2835: Support common dma-channel-mask

[Frank Li]

On Fri, May 24, 2024 at 07:26:46PM +0100, Dave Stevenson wrote:
> From: Stefan Wahren 
> 
> Nowadays there is a generic property for dma-channel-mask in the DMA
> controller binding. So prefer this one instead of the old vendor specific
> one. Print a warning in case the old one is used. Btw use the result of
> of_property_read_u32() as return code in error case.

Use generic 'dma-channel-mask' property. Print a warning in case the
old brcm,dma-channel-mask is used.

Did you update binding doc?

> 
> Signed-off-by: Stefan Wahren 
> Signed-off-by: Dave Stevenson 
> ---
>  drivers/dma/bcm2835-dma.c | 19 +--
>  1 file changed, 13 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/dma/bcm2835-dma.c b/drivers/dma/bcm2835-dma.c
> index 9d74fe97452e..528c4593b45a 100644
> --- a/drivers/dma/bcm2835-dma.c
> +++ b/drivers/dma/bcm2835-dma.c
> @@ -941,12 +941,19 @@ static int bcm2835_dma_probe(struct platform_device 
> *pdev)
>   }
>  
>   /* Request DMA channel mask from device tree */
> - if (of_property_read_u32(pdev->dev.of_node,
> - "brcm,dma-channel-mask",
> - _available)) {
> - dev_err(>dev, "Failed to get channel mask\n");
> - rc = -EINVAL;
> - goto err_no_dma;
> + rc = of_property_read_u32(pdev->dev.of_node, "dma-channel-mask",
> +   _available);
> +
> + if (rc) {
> + /* Try deprecated property */
> + if (of_property_read_u32(pdev->dev.of_node,
> +  "brcm,dma-channel-mask",
> +  _available)) {
> + dev_err(>dev, "Failed to get channel mask\n");
> + goto err_no_dma;
> + }
> +
> + dev_warn(>dev, "brcm,dma-channel-mask deprecated - please 
> update DT\n");
>   }
>  
>   /* get irqs for each channel that we support */
> -- 
> 2.34.1
> 

[med-svn] [Git][med-team/simrisc][upstream] New upstream version 16.01.00

[Frank B. Brokken (@fbb-guest)]

Frank B. Brokken pushed to branch upstream at Debian Med / simrisc


Commits:
9fefa13a by Frank B. Brokken at 2024-06-05T17:02:13+02:00
New upstream version 16.01.00
- - - - -


30 changed files:

- INSTALL.im
- VERSION
- analysis/run.cc
- changelog
- costs/cost.cc
- costs/costs.h
- costs/discount.cc
- costs/othertreatment.cc
- documentation/man/include/configfiles.yo
- documentation/man/simrisc.yo
- documentation/man/simriscparams.yo
- documentation/manual/simrisc.yo
- dot.config/simrisc
- icmake/beep
- + icmake/cxxdefine
- + loop/addbiopcosts.cc
- − loop/addcost.cc
- loop/caseinit.cc
- loop/characteristics.cc
- loop/cptindices.cc
- loop/data.cc
- + loop/falsenegative.cc
- loop/gencases.cc
- loop/headerdata.cc
- loop/headerrounds.cc
- loop/intervalcancer.cc
- loop/iterate.cc
- loop/leaving.cc
- + loop/left.cc
- loop/loop.h


The diff was not included because it is too large.


View it on GitLab: 
https://salsa.debian.org/med-team/simrisc/-/commit/9fefa13afb94240e6876f88c1c3298cbf77ef6e2

-- 
This project does not include diff previews in email notifications.
View it on GitLab: 
https://salsa.debian.org/med-team/simrisc/-/commit/9fefa13afb94240e6876f88c1c3298cbf77ef6e2
You're receiving this email because of your account on salsa.debian.org.


___
debian-med-commit mailing list
debian-med-com...@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-commit

[med-svn] [Git][med-team/simrisc][debian/latest] 3 commits: Ready for simrisc 16.01.00-1

[Frank B. Brokken (@fbb-guest)]

Frank B. Brokken pushed to branch debian/latest at Debian Med / simrisc


Commits:
963b3369 by Frank B. Brokken at 2024-06-05T17:02:10+02:00
Ready for simrisc 16.01.00-1

- - - - -
9fefa13a by Frank B. Brokken at 2024-06-05T17:02:13+02:00
New upstream version 16.01.00
- - - - -
7ac640ad by Frank B. Brokken at 2024-06-05T17:02:17+02:00
Update upstream source from tag upstream/16.01.00

Update to upstream version 16.01.00
with Debian dir 4867f3311751423174e33300abbfdccf96b0a8ba
- - - - -


30 changed files:

- INSTALL.im
- VERSION
- analysis/run.cc
- changelog
- costs/cost.cc
- costs/costs.h
- costs/discount.cc
- costs/othertreatment.cc
- debian/changelog
- debian/tests/simrisc-test1.expected.gz
- debian/tests/simrisc-test2.expected.gz
- documentation/man/include/configfiles.yo
- documentation/man/simrisc.yo
- documentation/man/simriscparams.yo
- documentation/manual/simrisc.yo
- dot.config/simrisc
- icmake/beep
- + icmake/cxxdefine
- + loop/addbiopcosts.cc
- − loop/addcost.cc
- loop/caseinit.cc
- loop/characteristics.cc
- loop/cptindices.cc
- loop/data.cc
- + loop/falsenegative.cc
- loop/gencases.cc
- loop/headerdata.cc
- loop/headerrounds.cc
- loop/intervalcancer.cc
- loop/iterate.cc


The diff was not included because it is too large.


View it on GitLab: 
https://salsa.debian.org/med-team/simrisc/-/compare/dae74bf0d44b00b5268cd56742cdb944ad68c54e...7ac640adb9e14b1ec952443ae235e5cf8f47a84e

-- 
This project does not include diff previews in email notifications.
View it on GitLab: 
https://salsa.debian.org/med-team/simrisc/-/compare/dae74bf0d44b00b5268cd56742cdb944ad68c54e...7ac640adb9e14b1ec952443ae235e5cf8f47a84e
You're receiving this email because of your account on salsa.debian.org.


___
debian-med-commit mailing list
debian-med-com...@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-commit

[med-svn] [Git][med-team/simrisc][pristine-tar] pristine-tar data for simrisc_16.01.00.orig.tar.gz

[Frank B. Brokken (@fbb-guest)]

Frank B. Brokken pushed to branch pristine-tar at Debian Med / simrisc


Commits:
519d94b6 by Frank B. Brokken at 2024-06-05T17:02:17+02:00
pristine-tar data for simrisc_16.01.00.orig.tar.gz

- - - - -


2 changed files:

- + simrisc_16.01.00.orig.tar.gz.delta
- + simrisc_16.01.00.orig.tar.gz.id


Changes:

=
simrisc_16.01.00.orig.tar.gz.delta
=
Binary files /dev/null and b/simrisc_16.01.00.orig.tar.gz.delta differ


=
simrisc_16.01.00.orig.tar.gz.id
=
@@ -0,0 +1 @@
+81809260e0e8acd95cc722ce0789cab51b0072b0



View it on GitLab: 
https://salsa.debian.org/med-team/simrisc/-/commit/519d94b6b9dc2698b3280f2ad6b4ebee6d71a58f

-- 
This project does not include diff previews in email notifications.
View it on GitLab: 
https://salsa.debian.org/med-team/simrisc/-/commit/519d94b6b9dc2698b3280f2ad6b4ebee6d71a58f
You're receiving this email because of your account on salsa.debian.org.


___
debian-med-commit mailing list
debian-med-com...@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-commit

Re: PS: virtualbox 7.0.16 and Windows 11 guest

[Frank]

Am Mittwoch, dem 05.06.2024 um 13:59 +0200 schrieb Frank:
> Am Freitag, dem 19.04.2024 um 17:31 +0200 schrieb Ralf Mardorf:
> > On Fri, 2024-04-19 at 16:47 +0200, Frank wrote:
> > > https://linuxtldr.com/windows-docker-container/
> > 
> > 
> I installed Win in the above mentioned docker container and that went
> pretty smooth, though I haven't figuered out how to share data with
> the
> host.
> One issue I have is that there's no sound output, does this work with
> Virtualbox?
> Frank
ok,
I've been playing around a little more and with the right settings in
Remmina I can connect to the container via RDP incl. data sharing
between host and client as well as sound in/output working.

Frank

Re: PS: virtualbox 7.0.16 and Windows 11 guest

[Frank]

Am Freitag, dem 19.04.2024 um 17:31 +0200 schrieb Ralf Mardorf:
> On Fri, 2024-04-19 at 16:47 +0200, Frank wrote:
> > https://linuxtldr.com/windows-docker-container/
> 
> Thank you. The article doesn't mention how to share data between
> "host"
> and "guest"/container. The article doesn't mention, if it's possible
> to
> migrate the license from my current Windows 11 install to the
> Docker's
Have you been able to further advance, either witht he docker setup or
your Virtualbox?
I installed Win in the above mentioned docker container and that went
pretty smooth, though I haven't figuered out how to share data with the
host.
One issue I have is that there's no sound output, does this work with
Virtualbox?
Frank

Re: Request permissions to Create KIP

[Frank Yang]

Hi Josep,

I just got Confluence account, too. Could you grant me the permission to create 
KIP as well? Thank you.

JIRA: yangpoan
Confluence: yangpoan

Best Regards,
PoAn Yang

> On Jun 5, 2024, at 7:35 PM, Josep Prat  wrote:
> 
> Hi!
> Thanks for your interest in Apache Kafka. Your accounts are now all set.
> 
> Best,
> 
> On Wed, Jun 5, 2024 at 1:32 PM Kuan Po Tseng  wrote:
> 
>> Hello everyone,
>> 
>> I hope this message finds you well.
>> I am writing to request permissions to create a KIP. Below are my JIRA and
>> Confluence IDs:
>> 
>> JIRA: brandboat
>> Confluence: brandboat
>> Could you please grant me the necessary permissions?
>> 
>> Thank you very much for your time and assistance.
>> 
>> Best regards,
>> Kuan Po Tseng
>> 
> 
> 
> -- 
> [image: Aiven] 
> 
> *Josep Prat*
> Open Source Engineering Director, *Aiven*
> josep.p...@aiven.io   |   +491715557497
> aiven.io    |   
>     
> *Aiven Deutschland GmbH*
> Alexanderufer 3-7, 10117 Berlin
> Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen
> Amtsgericht Charlottenburg, HRB 209739 B

[digikam] [Bug 488061] New: the tool Image Mosaic Wall will crashes

[Frank]

https://bugs.kde.org/show_bug.cgi?id=488061

Bug ID: 488061
   Summary: the tool Image Mosaic Wall will crashes
Classification: Applications
   Product: digikam
   Version: 8.3.0
  Platform: Microsoft Windows
OS: Microsoft Windows
Status: REPORTED
  Severity: normal
  Priority: NOR
 Component: ImageEditor-Plugins
  Assignee: digikam-bugs-n...@kde.org
  Reporter: fwi...@web.de
  Target Milestone: ---

Hello,
I would like to create a mosaic image using the Image Mosaic Wall... tool
(Extras/Image Mosaic Wall..), which works well with the standard grid settings
of 100 x 100. However, if I change the grid settings, e.g. 150 x 150, and then
click on "Create Mosaic", the entire digikam program usually crashes without an
error message. Sometimes you also get an error message that the read operation
could not be carried out in the memory.
Perhaps you can fix the problem in a future version.
Many thanks and best regards
Frank

STEPS TO REPRODUCE
1.  open the Tool Image Mosaic Wall
2.  create a mosaic with the default settings
3.  change the default settings (for example grid settings 150 x150)
4. click the button "Create Mosaic" the program will crashes immediately

OBSERVED RESULT
- the program crashes immediately

EXPECTED RESULT
- creation of the mosaic

SOFTWARE/OS VERSIONS
Windows: 11 
macOS: 
Linux/KDE Plasma: 
(available in About System)
KDE Plasma Version: 
KDE Frameworks Version: 
Qt Version: 

ADDITIONAL INFORMATION

-- 
You are receiving this mail because:
You are watching all bug changes.

[FFmpeg-devel] [PATCH v2 2/2] lavc/vvc: Prevent overflow in chroma QP derivation

[Frank Plowman]

On the top of p. 112 in VVC (09/2023):

It is a requirement of bitstream conformance that the values of
qpInVal[ i ][ j ] and qpOutVal[ i ][ j ] shall be in the range
of −QpBdOffset to 63, inclusive for i in the range of 0 to
numQpTables − 1, inclusive, and j in the range of 0 to
sps_num_points_in_qp_table_minus1[ i ] + 1, inclusive.

Signed-off-by: Frank Plowman 
---
 libavcodec/vvc/ps.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/libavcodec/vvc/ps.c b/libavcodec/vvc/ps.c
index bfc3c121fd..c4f64d5da7 100644
--- a/libavcodec/vvc/ps.c
+++ b/libavcodec/vvc/ps.c
@@ -101,9 +101,14 @@ static int sps_chroma_qp_table(VVCSPS *sps)
 
 qp_out[0] = qp_in[0] = r->sps_qp_table_start_minus26[i] + 26;
 for (int j = 0; j < num_points_in_qp_table; j++ ) {
+const uint8_t delta_qp_out = (r->sps_delta_qp_in_val_minus1[i][j] 
^ r->sps_delta_qp_diff_val[i][j]);
 delta_qp_in[j] = r->sps_delta_qp_in_val_minus1[i][j] + 1;
+if (qp_in[j] + delta_qp_in[j] > 63)
+return AVERROR(EINVAL);
 qp_in[j+1] = qp_in[j] + delta_qp_in[j];
-qp_out[j+1] = qp_out[j] + (r->sps_delta_qp_in_val_minus1[i][j] ^ 
r->sps_delta_qp_diff_val[i][j]);
+if (qp_out[j] + delta_qp_out > 63)
+return AVERROR(EINVAL);
+qp_out[j+1] = qp_out[j] + delta_qp_out;
 }
 sps->chroma_qp_table[i][qp_in[0] + off] = qp_out[0];
 for (int k = qp_in[0] - 1 + off; k >= 0; k--)
-- 
2.45.1

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH v2 1/2] lavc/vvc: Use sps_chroma_qp_table return code

[Frank Plowman]

Signed-off-by: Frank Plowman 
---
 libavcodec/vvc/ps.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/libavcodec/vvc/ps.c b/libavcodec/vvc/ps.c
index 1b23675c98..bfc3c121fd 100644
--- a/libavcodec/vvc/ps.c
+++ b/libavcodec/vvc/ps.c
@@ -186,8 +186,11 @@ static int sps_derive(VVCSPS *sps, void *log_ctx)
 sps_inter(sps);
 sps_partition_constraints(sps);
 sps_ladf(sps);
-if (r->sps_chroma_format_idc != 0)
-sps_chroma_qp_table(sps);
+if (r->sps_chroma_format_idc != 0) {
+ret = sps_chroma_qp_table(sps);
+if (ret < 0)
+return ret;
+}
 
 return 0;
 }
-- 
2.45.1

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH] lavc/vvc: Prevent overflow in chroma QP derivation

[Frank Plowman]

On the top of p. 112 in VVC (09/2023):

It is a requirement of bitstream conformance that the values of
qpInVal[ i ][ j ] and qpOutVal[ i ][ j ] shall be in the range
of −QpBdOffset to 63, inclusive for i in the range of 0 to
numQpTables − 1, inclusive, and j in the range of 0 to
sps_num_points_in_qp_table_minus1[ i ] + 1, inclusive.

Signed-off-by: Frank Plowman 
---
 libavcodec/vvc/ps.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/libavcodec/vvc/ps.c b/libavcodec/vvc/ps.c
index 1b23675c98..b024caf460 100644
--- a/libavcodec/vvc/ps.c
+++ b/libavcodec/vvc/ps.c
@@ -101,9 +101,14 @@ static int sps_chroma_qp_table(VVCSPS *sps)
 
 qp_out[0] = qp_in[0] = r->sps_qp_table_start_minus26[i] + 26;
 for (int j = 0; j < num_points_in_qp_table; j++ ) {
+const uint8_t delta_qp_out = (r->sps_delta_qp_in_val_minus1[i][j] 
^ r->sps_delta_qp_diff_val[i][j]);
 delta_qp_in[j] = r->sps_delta_qp_in_val_minus1[i][j] + 1;
+if (qp_in[j] + delta_qp_in[j] > 63)
+return AVERROR_INVALIDDATA;
 qp_in[j+1] = qp_in[j] + delta_qp_in[j];
-qp_out[j+1] = qp_out[j] + (r->sps_delta_qp_in_val_minus1[i][j] ^ 
r->sps_delta_qp_diff_val[i][j]);
+if (qp_out[j] + delta_qp_out > 63)
+return AVERROR_INVALIDDATA;
+qp_out[j+1] = qp_out[j] + delta_qp_out;
 }
 sps->chroma_qp_table[i][qp_in[0] + off] = qp_out[0];
 for (int k = qp_in[0] - 1 + off; k >= 0; k--)
-- 
2.45.1

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[Bug 2064321] Re: Power guest secure boot with key management: kernel portion

[Frank Heimes]

Hello, is there already a list of (kernel) commits that are required?
(So that we can check whether they are incl. in the Ubuntu kernel or not; and 
in case not do the submissions to the Ubuntu kernel team.)

** Changed in: ubuntu-power-systems
 Assignee: (unassigned) => Ubuntu on IBM Power Systems Bug Triage 
(ubuntu-power-triage)

** Changed in: ubuntu-power-systems
   Importance: Undecided => High

** Changed in: linux (Ubuntu)
   Importance: Undecided => High

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2064321

Title:
  Power guest secure boot with key management: kernel portion

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-power-systems/+bug/2064321/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 2064345] Re: Power guest secure boot with key management: userspace portion

[Frank Heimes]

Since this is about a new ppc64el specific tool ("secvarctl", that does not yet 
exists in LP),
I'll marked this ticket as temp. affecting "powerpc-utils", until we have a 
first upload.

** Changed in: ubuntu-power-systems
 Assignee: (unassigned) => Ubuntu on IBM Power Systems Bug Triage 
(ubuntu-power-triage)

** Changed in: linux (Ubuntu)
 Assignee: Ubuntu on IBM Power Systems Bug Triage (ubuntu-power-triage) => 
(unassigned)

** Package changed: linux (Ubuntu) => powerpc-utils (Ubuntu)

** Changed in: powerpc-utils (Ubuntu)
 Assignee: (unassigned) => Patricia Domingues (patriciasd)

** Changed in: ubuntu-power-systems
   Importance: Undecided => High

** Changed in: powerpc-utils (Ubuntu)
   Importance: Undecided => High

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2064345

Title:
  Power guest secure boot with key management: userspace portion

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-power-systems/+bug/2064345/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 2064345] Re: Power guest secure boot with key management: userspace portion

[Frank Heimes]

I'm assuming that this is the upstream repository of 'secvarctl':
https://github.com/open-power/secvarctl

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2064345

Title:
  Power guest secure boot with key management: userspace portion

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-power-systems/+bug/2064345/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Re: [PATCH 0/6] Introduce extension implied rules

[Frank Chang]

Patchset resend:
https://lists.gnu.org/archive/html/qemu-riscv/2024-06/msg00130.html


 於 2024年6月3日 週一 下午2:07寫道：

> From: Frank Chang 
>
> Currently, the implied extensions are enabled and checked in
> riscv_cpu_validate_set_extensions(). However, the order of enabling the
> implied extensions must follow a strict sequence, which is error-prone.
>
> This patchset introduce extension implied rule helpers to enable the
> implied extensions. This also eliminates the old-fashioned ordering
> requirement. For example, Zvksg implies Zvks, Zvks implies Zvksed, etc.,
> removing the need to check the implied rules of Zvksg before Zvks.
>
> The idea [1] and the implied rules [2] are referenced from LLVM.
>
> [1]
> https://github.com/llvm/llvm-project/blob/main/llvm/lib/TargetParser/RISCVISAInfo.cpp#L875
> [2]
> https://github.com/llvm/llvm-project/blob/main/llvm/lib/Target/RISCV/RISCVFeatures.td
>
> Frank Chang (6):
>   target/riscv: Introduce extension implied rules definition
>   target/riscv: Introduce extension implied rule helpers
>   target/riscv: Add MISA implied rules
>   target/riscv: Add standard extension implied rules
>   target/riscv: Add Zc extension implied rule
>   target/riscv: Remove extension auto-update check statements
>
>  target/riscv/cpu.c | 396 +
>  target/riscv/cpu.h |  17 ++
>  target/riscv/tcg/tcg-cpu.c | 233 +++---
>  3 files changed, 531 insertions(+), 115 deletions(-)
>
> --
> 2.43.2
>
>
>

[PATCH RESEND 6/6] target/riscv: Remove extension auto-update check statements

[frank . chang]

From: Frank Chang 

Remove the old-fashioned extension auto-update check statements as
they are replaced by the extension implied rules.

Signed-off-by: Frank Chang 
---
 target/riscv/tcg/tcg-cpu.c | 115 -
 1 file changed, 115 deletions(-)

diff --git a/target/riscv/tcg/tcg-cpu.c b/target/riscv/tcg/tcg-cpu.c
index ed10ac799a..c1926db370 100644
--- a/target/riscv/tcg/tcg-cpu.c
+++ b/target/riscv/tcg/tcg-cpu.c
@@ -469,10 +469,6 @@ void riscv_cpu_validate_set_extensions(RISCVCPU *cpu, 
Error **errp)
 return;
 }
 
-if (cpu->cfg.ext_zfh) {
-cpu_cfg_ext_auto_update(cpu, CPU_CFG_OFFSET(ext_zfhmin), true);
-}
-
 if (cpu->cfg.ext_zfhmin && !riscv_has_ext(env, RVF)) {
 error_setg(errp, "Zfh/Zfhmin extensions require F extension");
 return;
@@ -494,9 +490,6 @@ void riscv_cpu_validate_set_extensions(RISCVCPU *cpu, Error 
**errp)
 error_propagate(errp, local_err);
 return;
 }
-
-/* The V vector extension depends on the Zve64d extension */
-cpu_cfg_ext_auto_update(cpu, CPU_CFG_OFFSET(ext_zve64d), true);
 }
 
 /* The Zve64d extension depends on the Zve64f extension */
@@ -505,18 +498,6 @@ void riscv_cpu_validate_set_extensions(RISCVCPU *cpu, 
Error **errp)
 error_setg(errp, "Zve64d/V extensions require D extension");
 return;
 }
-cpu_cfg_ext_auto_update(cpu, CPU_CFG_OFFSET(ext_zve64f), true);
-}
-
-/* The Zve64f extension depends on the Zve64x and Zve32f extensions */
-if (cpu->cfg.ext_zve64f) {
-cpu_cfg_ext_auto_update(cpu, CPU_CFG_OFFSET(ext_zve64x), true);
-cpu_cfg_ext_auto_update(cpu, CPU_CFG_OFFSET(ext_zve32f), true);
-}
-
-/* The Zve64x extension depends on the Zve32x extension */
-if (cpu->cfg.ext_zve64x) {
-cpu_cfg_ext_auto_update(cpu, CPU_CFG_OFFSET(ext_zve32x), true);
 }
 
 /* The Zve32f extension depends on the Zve32x extension */
@@ -525,11 +506,6 @@ void riscv_cpu_validate_set_extensions(RISCVCPU *cpu, 
Error **errp)
 error_setg(errp, "Zve32f/Zve64f extensions require F extension");
 return;
 }
-cpu_cfg_ext_auto_update(cpu, CPU_CFG_OFFSET(ext_zve32x), true);
-}
-
-if (cpu->cfg.ext_zvfh) {
-cpu_cfg_ext_auto_update(cpu, CPU_CFG_OFFSET(ext_zvfhmin), true);
 }
 
 if (cpu->cfg.ext_zvfhmin && !cpu->cfg.ext_zve32f) {
@@ -552,11 +528,6 @@ void riscv_cpu_validate_set_extensions(RISCVCPU *cpu, 
Error **errp)
 return;
 }
 
-/* Set the ISA extensions, checks should have happened above */
-if (cpu->cfg.ext_zhinx) {
-cpu_cfg_ext_auto_update(cpu, CPU_CFG_OFFSET(ext_zca), true);
-}
-
 if ((cpu->cfg.ext_zdinx || cpu->cfg.ext_zhinxmin) && !cpu->cfg.ext_zfinx) {
 error_setg(errp, "Zdinx/Zhinx/Zhinxmin extensions require Zfinx");
 return;
@@ -574,27 +545,6 @@ void riscv_cpu_validate_set_extensions(RISCVCPU *cpu, 
Error **errp)
 }
 }
 
-if (cpu->cfg.ext_zce) {
-cpu_cfg_ext_auto_update(cpu, CPU_CFG_OFFSET(ext_zca), true);
-cpu_cfg_ext_auto_update(cpu, CPU_CFG_OFFSET(ext_zcb), true);
-cpu_cfg_ext_auto_update(cpu, CPU_CFG_OFFSET(ext_zcmp), true);
-cpu_cfg_ext_auto_update(cpu, CPU_CFG_OFFSET(ext_zcmt), true);
-if (riscv_has_ext(env, RVF) && mcc->misa_mxl_max == MXL_RV32) {
-cpu_cfg_ext_auto_update(cpu, CPU_CFG_OFFSET(ext_zcf), true);
-}
-}
-
-/* zca, zcd and zcf has a PRIV 1.12.0 restriction */
-if (riscv_has_ext(env, RVC) && env->priv_ver >= PRIV_VERSION_1_12_0) {
-cpu_cfg_ext_auto_update(cpu, CPU_CFG_OFFSET(ext_zca), true);
-if (riscv_has_ext(env, RVF) && mcc->misa_mxl_max == MXL_RV32) {
-cpu_cfg_ext_auto_update(cpu, CPU_CFG_OFFSET(ext_zcf), true);
-}
-if (riscv_has_ext(env, RVD)) {
-cpu_cfg_ext_auto_update(cpu, CPU_CFG_OFFSET(ext_zcd), true);
-}
-}
-
 if (mcc->misa_mxl_max != MXL_RV32 && cpu->cfg.ext_zcf) {
 error_setg(errp, "Zcf extension is only relevant to RV32");
 return;
@@ -628,48 +578,6 @@ void riscv_cpu_validate_set_extensions(RISCVCPU *cpu, 
Error **errp)
 return;
 }
 
-/*
- * Shorthand vector crypto extensions
- */
-if (cpu->cfg.ext_zvknc) {
-cpu_cfg_ext_auto_update(cpu, CPU_CFG_OFFSET(ext_zvkn), true);
-cpu_cfg_ext_auto_update(cpu, CPU_CFG_OFFSET(ext_zvbc), true);
-}
-
-if (cpu->cfg.ext_zvkng) {
-cpu_cfg_ext_auto_update(cpu, CPU_CFG_OFFSET(ext_zvkn), true);
-cpu_cfg_ext_auto_update(cpu, CPU_CFG_OFFSET(ext_zvkg), true);
-}
-
-if (cpu->cfg.ext_zvkn) {
-cpu_cfg_ext_auto_update(cpu, CPU_CFG_OFFSET(ext_zvkned), true);
-cpu_cfg_ext_auto_update(cpu

[PATCH RESEND 1/6] target/riscv: Introduce extension implied rules definition

[frank . chang]

From: Frank Chang 

RISCVCPUImpliedExtsRule is created to store the implied rules.
'is_misa' flag is used to distinguish whether the rule is derived
from the MISA or other extensions.
'ext' stores the MISA bit if 'is_misa' is true. Otherwise, it stores
the offset of the extension defined in RISCVCPUConfig. 'ext' will also
serve as the key of the hash tables to look up the rule in the following
commit.

Signed-off-by: Frank Chang 
---
 target/riscv/cpu.c |  8 
 target/riscv/cpu.h | 18 ++
 2 files changed, 26 insertions(+)

diff --git a/target/riscv/cpu.c b/target/riscv/cpu.c
index cee6fc4a9a..c7e5cec7ef 100644
--- a/target/riscv/cpu.c
+++ b/target/riscv/cpu.c
@@ -2242,6 +2242,14 @@ RISCVCPUProfile *riscv_profiles[] = {
 NULL,
 };
 
+RISCVCPUImpliedExtsRule *riscv_misa_implied_rules[] = {
+NULL
+};
+
+RISCVCPUImpliedExtsRule *riscv_ext_implied_rules[] = {
+NULL
+};
+
 static Property riscv_cpu_properties[] = {
 DEFINE_PROP_BOOL("debug", RISCVCPU, cfg.debug, true),
 
diff --git a/target/riscv/cpu.h b/target/riscv/cpu.h
index 1501868008..b5a036cf27 100644
--- a/target/riscv/cpu.h
+++ b/target/riscv/cpu.h
@@ -122,6 +122,24 @@ typedef enum {
 EXT_STATUS_DIRTY,
 } RISCVExtStatus;
 
+typedef struct riscv_cpu_implied_exts_rule RISCVCPUImpliedExtsRule;
+
+struct riscv_cpu_implied_exts_rule {
+/* Bitmask indicates the rule enabled status for the harts. */
+uint64_t enabled;
+/* True if this is a MISA implied rule. */
+bool is_misa;
+/* ext is MISA bit if is_misa flag is true, else extension offset. */
+const uint32_t ext;
+const uint32_t implied_misas;
+const uint32_t implied_exts[];
+};
+
+extern RISCVCPUImpliedExtsRule *riscv_misa_implied_rules[];
+extern RISCVCPUImpliedExtsRule *riscv_ext_implied_rules[];
+
+#define RISCV_IMPLIED_EXTS_RULE_END -1
+
 #define MMU_USER_IDX 3
 
 #define MAX_RISCV_PMPS (16)
-- 
2.43.2

[PATCH RESEND 0/6] Introduce extension implied rules

[frank . chang]

From: Frank Chang 

Currently, the implied extensions are enabled and checked in
riscv_cpu_validate_set_extensions(). However, the order of enabling the
implied extensions must follow a strict sequence, which is error-prone.

This patchset introduce extension implied rule helpers to enable the
implied extensions. This also eliminates the old-fashioned ordering
requirement. For example, Zvksg implies Zvks, Zvks implies Zvksed, etc.,
removing the need to check the implied rules of Zvksg before Zvks.

The idea [1] and the implied rules [2] are referenced from LLVM.

[1] 
https://github.com/llvm/llvm-project/blob/main/llvm/lib/TargetParser/RISCVISAInfo.cpp#L875
[2] 
https://github.com/llvm/llvm-project/blob/main/llvm/lib/Target/RISCV/RISCVFeatures.td

Frank Chang (6):
  target/riscv: Introduce extension implied rules definition
  target/riscv: Introduce extension implied rule helpers
  target/riscv: Add MISA implied rules
  target/riscv: Add standard extension implied rules
  target/riscv: Add Zc extension implied rule
  target/riscv: Remove extension auto-update check statements

 target/riscv/cpu.c | 396 +
 target/riscv/cpu.h |  18 ++
 target/riscv/tcg/tcg-cpu.c | 238 +++---
 3 files changed, 537 insertions(+), 115 deletions(-)

--
2.43.2

[PATCH RESEND 4/6] target/riscv: Add standard extension implied rules

[frank . chang]

From: Frank Chang 

Add standard extension implied rules to enable the implied extensions of
the standard extension recursively.

Signed-off-by: Frank Chang 
---
 target/riscv/cpu.c | 340 +
 1 file changed, 340 insertions(+)

diff --git a/target/riscv/cpu.c b/target/riscv/cpu.c
index a6e9055c5f..80b238060a 100644
--- a/target/riscv/cpu.c
+++ b/target/riscv/cpu.c
@@ -2289,12 +2289,352 @@ static RISCVCPUImpliedExtsRule RVV_IMPLIED = {
 },
 };
 
+static RISCVCPUImpliedExtsRule ZCB_IMPLIED = {
+.ext = CPU_CFG_OFFSET(ext_zcb),
+.implied_exts = {
+CPU_CFG_OFFSET(ext_zca),
+
+RISCV_IMPLIED_EXTS_RULE_END
+},
+};
+
+static RISCVCPUImpliedExtsRule ZCD_IMPLIED = {
+.ext = CPU_CFG_OFFSET(ext_zcd),
+.implied_misas = RVD,
+.implied_exts = {
+CPU_CFG_OFFSET(ext_zca),
+
+RISCV_IMPLIED_EXTS_RULE_END
+},
+};
+
+static RISCVCPUImpliedExtsRule ZCE_IMPLIED = {
+.ext = CPU_CFG_OFFSET(ext_zce),
+.implied_exts = {
+CPU_CFG_OFFSET(ext_zcb), CPU_CFG_OFFSET(ext_zcmp),
+CPU_CFG_OFFSET(ext_zcmt),
+
+RISCV_IMPLIED_EXTS_RULE_END
+},
+};
+
+static RISCVCPUImpliedExtsRule ZCF_IMPLIED = {
+.ext = CPU_CFG_OFFSET(ext_zcf),
+.implied_misas = RVF,
+.implied_exts = {
+CPU_CFG_OFFSET(ext_zca),
+
+RISCV_IMPLIED_EXTS_RULE_END
+},
+};
+
+static RISCVCPUImpliedExtsRule ZCMP_IMPLIED = {
+.ext = CPU_CFG_OFFSET(ext_zcmp),
+.implied_exts = {
+CPU_CFG_OFFSET(ext_zca),
+
+RISCV_IMPLIED_EXTS_RULE_END
+},
+};
+
+static RISCVCPUImpliedExtsRule ZCMT_IMPLIED = {
+.ext = CPU_CFG_OFFSET(ext_zcmt),
+.implied_exts = {
+CPU_CFG_OFFSET(ext_zca), CPU_CFG_OFFSET(ext_zicsr),
+
+RISCV_IMPLIED_EXTS_RULE_END
+},
+};
+
+static RISCVCPUImpliedExtsRule ZDINX_IMPLIED = {
+.ext = CPU_CFG_OFFSET(ext_zdinx),
+.implied_exts = {
+CPU_CFG_OFFSET(ext_zfinx),
+
+RISCV_IMPLIED_EXTS_RULE_END
+},
+};
+
+static RISCVCPUImpliedExtsRule ZFA_IMPLIED = {
+.ext = CPU_CFG_OFFSET(ext_zfa),
+.implied_misas = RVF,
+.implied_exts = { RISCV_IMPLIED_EXTS_RULE_END },
+};
+
+static RISCVCPUImpliedExtsRule ZFBFMIN_IMPLIED = {
+.ext = CPU_CFG_OFFSET(ext_zfbfmin),
+.implied_misas = RVF,
+.implied_exts = { RISCV_IMPLIED_EXTS_RULE_END },
+};
+
+static RISCVCPUImpliedExtsRule ZFH_IMPLIED = {
+.ext = CPU_CFG_OFFSET(ext_zfh),
+.implied_exts = {
+CPU_CFG_OFFSET(ext_zfhmin),
+
+RISCV_IMPLIED_EXTS_RULE_END
+},
+};
+
+static RISCVCPUImpliedExtsRule ZFHMIN_IMPLIED = {
+.ext = CPU_CFG_OFFSET(ext_zfhmin),
+.implied_misas = RVF,
+.implied_exts = { RISCV_IMPLIED_EXTS_RULE_END },
+};
+
+static RISCVCPUImpliedExtsRule ZFINX_IMPLIED = {
+.ext = CPU_CFG_OFFSET(ext_zfinx),
+.implied_exts = {
+CPU_CFG_OFFSET(ext_zicsr),
+
+RISCV_IMPLIED_EXTS_RULE_END
+},
+};
+
+static RISCVCPUImpliedExtsRule ZHINX_IMPLIED = {
+.ext = CPU_CFG_OFFSET(ext_zhinx),
+.implied_exts = {
+CPU_CFG_OFFSET(ext_zhinxmin),
+
+RISCV_IMPLIED_EXTS_RULE_END
+},
+};
+
+static RISCVCPUImpliedExtsRule ZHINXMIN_IMPLIED = {
+.ext = CPU_CFG_OFFSET(ext_zhinxmin),
+.implied_exts = {
+CPU_CFG_OFFSET(ext_zfinx),
+
+RISCV_IMPLIED_EXTS_RULE_END
+},
+};
+
+static RISCVCPUImpliedExtsRule ZICNTR_IMPLIED = {
+.ext = CPU_CFG_OFFSET(ext_zicntr),
+.implied_exts = {
+CPU_CFG_OFFSET(ext_zicsr),
+
+RISCV_IMPLIED_EXTS_RULE_END
+},
+};
+
+static RISCVCPUImpliedExtsRule ZIHPM_IMPLIED = {
+.ext = CPU_CFG_OFFSET(ext_zihpm),
+.implied_exts = {
+CPU_CFG_OFFSET(ext_zicsr),
+
+RISCV_IMPLIED_EXTS_RULE_END
+},
+};
+
+static RISCVCPUImpliedExtsRule ZK_IMPLIED = {
+.ext = CPU_CFG_OFFSET(ext_zk),
+.implied_exts = {
+CPU_CFG_OFFSET(ext_zkn), CPU_CFG_OFFSET(ext_zkr),
+CPU_CFG_OFFSET(ext_zkt),
+
+RISCV_IMPLIED_EXTS_RULE_END
+},
+};
+
+static RISCVCPUImpliedExtsRule ZKN_IMPLIED = {
+.ext = CPU_CFG_OFFSET(ext_zkn),
+.implied_exts = {
+CPU_CFG_OFFSET(ext_zbkb), CPU_CFG_OFFSET(ext_zbkc),
+CPU_CFG_OFFSET(ext_zbkx), CPU_CFG_OFFSET(ext_zkne),
+CPU_CFG_OFFSET(ext_zknd), CPU_CFG_OFFSET(ext_zknh),
+
+RISCV_IMPLIED_EXTS_RULE_END
+},
+};
+
+static RISCVCPUImpliedExtsRule ZKS_IMPLIED = {
+.ext = CPU_CFG_OFFSET(ext_zks),
+.implied_exts = {
+CPU_CFG_OFFSET(ext_zbkb), CPU_CFG_OFFSET(ext_zbkc),
+CPU_CFG_OFFSET(ext_zbkx), CPU_CFG_OFFSET(ext_zksed),
+CPU_CFG_OFFSET(ext_zksh),
+
+RISCV_IMPLIED_EXTS_RULE_END
+},
+};
+
+static RISCVCPUImpliedExtsRule ZVBB_IMPLIED = {
+.ext = CPU_CFG_OFFSET(ext_zvbb),
+.implied_exts = {
+CPU_CFG_OFFSET(ext_zvkb),
+
+RISCV_IMPLIED_EXTS_RULE_END
+},
+};
+
+static RISCVCPUImpliedExtsRule ZVE32F_IMPLIED = {
+.ext = CPU_CFG_OFFSET(ext_zve32f),
+.implied_misas = RVF

[PATCH RESEND 2/6] target/riscv: Introduce extension implied rule helpers

[frank . chang]

From: Frank Chang 

Introduce helpers to enable the extensions based on the implied rules.
The implied extensions are enabled recursively, so we don't have to
expand all of them manually. This also eliminates the old-fashioned
ordering requirement. For example, Zvksg implies Zvks, Zvks implies
Zvksed, etc., removing the need to check the implied rules of Zvksg
before Zvks.

Signed-off-by: Frank Chang 
---
 target/riscv/tcg/tcg-cpu.c | 89 ++
 1 file changed, 89 insertions(+)

diff --git a/target/riscv/tcg/tcg-cpu.c b/target/riscv/tcg/tcg-cpu.c
index 683f604d9f..899d605d36 100644
--- a/target/riscv/tcg/tcg-cpu.c
+++ b/target/riscv/tcg/tcg-cpu.c
@@ -36,6 +36,9 @@
 static GHashTable *multi_ext_user_opts;
 static GHashTable *misa_ext_user_opts;
 
+static GHashTable *misa_implied_rules;
+static GHashTable *ext_implied_rules;
+
 static bool cpu_cfg_ext_is_user_set(uint32_t ext_offset)
 {
 return g_hash_table_contains(multi_ext_user_opts,
@@ -833,11 +836,95 @@ static void riscv_cpu_validate_profiles(RISCVCPU *cpu)
 }
 }
 
+static void riscv_cpu_init_implied_exts_rules(void)
+{
+RISCVCPUImpliedExtsRule *rule;
+int i;
+
+for (i = 0; (rule = riscv_misa_implied_rules[i]); i++) {
+g_hash_table_insert(misa_implied_rules, GUINT_TO_POINTER(rule->ext),
+(gpointer)rule);
+}
+
+for (i = 0; (rule = riscv_ext_implied_rules[i]); i++) {
+g_hash_table_insert(ext_implied_rules, GUINT_TO_POINTER(rule->ext),
+(gpointer)rule);
+}
+}
+
+static void cpu_enable_implied_rule(RISCVCPU *cpu,
+RISCVCPUImpliedExtsRule *rule)
+{
+CPURISCVState *env = >env;
+RISCVCPUImpliedExtsRule *ir;
+target_ulong hartid = 0;
+int i;
+
+#if !defined(CONFIG_USER_ONLY)
+hartid = env->mhartid;
+#endif
+
+if (!(rule->enabled & BIT_ULL(hartid))) {
+/* Enable the implied MISAs. */
+if (rule->implied_misas) {
+riscv_cpu_set_misa_ext(env, env->misa_ext | rule->implied_misas);
+
+for (i = 0; misa_bits[i] != 0; i++) {
+if (rule->implied_misas & misa_bits[i]) {
+ir = g_hash_table_lookup(misa_implied_rules,
+ GUINT_TO_POINTER(misa_bits[i]));
+
+if (ir) {
+cpu_enable_implied_rule(cpu, ir);
+}
+}
+}
+}
+
+/* Enable the implied extensions. */
+for (i = 0; rule->implied_exts[i] != RISCV_IMPLIED_EXTS_RULE_END; i++) 
{
+cpu_cfg_ext_auto_update(cpu, rule->implied_exts[i], true);
+
+ir = g_hash_table_lookup(ext_implied_rules,
+ GUINT_TO_POINTER(rule->implied_exts[i]));
+
+if (ir) {
+cpu_enable_implied_rule(cpu, ir);
+}
+}
+
+rule->enabled |= BIT_ULL(hartid);
+}
+}
+
+static void riscv_cpu_enable_implied_rules(RISCVCPU *cpu)
+{
+RISCVCPUImpliedExtsRule *rule;
+int i;
+
+/* Enable the implied MISAs. */
+for (i = 0; (rule = riscv_misa_implied_rules[i]); i++) {
+if (riscv_has_ext(>env, rule->ext)) {
+cpu_enable_implied_rule(cpu, rule);
+}
+}
+
+/* Enable the implied extensions. */
+for (i = 0; (rule = riscv_ext_implied_rules[i]); i++) {
+if (isa_ext_is_enabled(cpu, rule->ext)) {
+cpu_enable_implied_rule(cpu, rule);
+}
+}
+}
+
 void riscv_tcg_cpu_finalize_features(RISCVCPU *cpu, Error **errp)
 {
 CPURISCVState *env = >env;
 Error *local_err = NULL;
 
+riscv_cpu_init_implied_exts_rules();
+riscv_cpu_enable_implied_rules(cpu);
+
 riscv_cpu_validate_misa_priv(env, _err);
 if (local_err != NULL) {
 error_propagate(errp, local_err);
@@ -1343,6 +1430,8 @@ static void riscv_tcg_cpu_instance_init(CPUState *cs)
 
 misa_ext_user_opts = g_hash_table_new(NULL, g_direct_equal);
 multi_ext_user_opts = g_hash_table_new(NULL, g_direct_equal);
+misa_implied_rules = g_hash_table_new(NULL, g_direct_equal);
+ext_implied_rules = g_hash_table_new(NULL, g_direct_equal);
 riscv_cpu_add_user_properties(obj);
 
 if (riscv_cpu_has_max_extensions(obj)) {
-- 
2.43.2

[PATCH RESEND 5/6] target/riscv: Add Zc extension implied rule

[frank . chang]

From: Frank Chang 

Zc extension has special implied rules that need to be handled separately.

Signed-off-by: Frank Chang 
---
 target/riscv/tcg/tcg-cpu.c | 34 ++
 1 file changed, 34 insertions(+)

diff --git a/target/riscv/tcg/tcg-cpu.c b/target/riscv/tcg/tcg-cpu.c
index 899d605d36..ed10ac799a 100644
--- a/target/riscv/tcg/tcg-cpu.c
+++ b/target/riscv/tcg/tcg-cpu.c
@@ -897,11 +897,45 @@ static void cpu_enable_implied_rule(RISCVCPU *cpu,
 }
 }
 
+/* Zc extension has special implied rules that need to be handled separately. 
*/
+static void cpu_enable_zc_implied_rules(RISCVCPU *cpu)
+{
+RISCVCPUClass *mcc = RISCV_CPU_GET_CLASS(cpu);
+CPURISCVState *env = >env;
+
+if (cpu->cfg.ext_zce) {
+cpu_cfg_ext_auto_update(cpu, CPU_CFG_OFFSET(ext_zca), true);
+cpu_cfg_ext_auto_update(cpu, CPU_CFG_OFFSET(ext_zcb), true);
+cpu_cfg_ext_auto_update(cpu, CPU_CFG_OFFSET(ext_zcmp), true);
+cpu_cfg_ext_auto_update(cpu, CPU_CFG_OFFSET(ext_zcmt), true);
+
+if (riscv_has_ext(env, RVF) && mcc->misa_mxl_max == MXL_RV32) {
+cpu_cfg_ext_auto_update(cpu, CPU_CFG_OFFSET(ext_zcf), true);
+}
+}
+
+/* Zca, Zcd and Zcf has a PRIV 1.12.0 restriction */
+if (riscv_has_ext(env, RVC) && env->priv_ver >= PRIV_VERSION_1_12_0) {
+cpu_cfg_ext_auto_update(cpu, CPU_CFG_OFFSET(ext_zca), true);
+
+if (riscv_has_ext(env, RVF) && mcc->misa_mxl_max == MXL_RV32) {
+cpu_cfg_ext_auto_update(cpu, CPU_CFG_OFFSET(ext_zcf), true);
+}
+
+if (riscv_has_ext(env, RVD)) {
+cpu_cfg_ext_auto_update(cpu, CPU_CFG_OFFSET(ext_zcd), true);
+}
+}
+}
+
 static void riscv_cpu_enable_implied_rules(RISCVCPU *cpu)
 {
 RISCVCPUImpliedExtsRule *rule;
 int i;
 
+/* Enable the implied extensions for Zc. */
+cpu_enable_zc_implied_rules(cpu);
+
 /* Enable the implied MISAs. */
 for (i = 0; (rule = riscv_misa_implied_rules[i]); i++) {
 if (riscv_has_ext(>env, rule->ext)) {
-- 
2.43.2

[PATCH RESEND 3/6] target/riscv: Add MISA implied rules

[frank . chang]

From: Frank Chang 

Add MISA extension implied rules to enable the implied extensions
of MISA recursively.

Signed-off-by: Frank Chang 
---
 target/riscv/cpu.c | 50 +-
 1 file changed, 49 insertions(+), 1 deletion(-)

diff --git a/target/riscv/cpu.c b/target/riscv/cpu.c
index c7e5cec7ef..a6e9055c5f 100644
--- a/target/riscv/cpu.c
+++ b/target/riscv/cpu.c
@@ -2242,8 +2242,56 @@ RISCVCPUProfile *riscv_profiles[] = {
 NULL,
 };
 
+static RISCVCPUImpliedExtsRule RVA_IMPLIED = {
+.is_misa = true,
+.ext = RVA,
+.implied_exts = {
+CPU_CFG_OFFSET(ext_zalrsc), CPU_CFG_OFFSET(ext_zaamo),
+
+RISCV_IMPLIED_EXTS_RULE_END
+},
+};
+
+static RISCVCPUImpliedExtsRule RVD_IMPLIED = {
+.is_misa = true,
+.ext = RVD,
+.implied_misas = RVF,
+.implied_exts = { RISCV_IMPLIED_EXTS_RULE_END },
+};
+
+static RISCVCPUImpliedExtsRule RVF_IMPLIED = {
+.is_misa = true,
+.ext = RVF,
+.implied_exts = {
+CPU_CFG_OFFSET(ext_zicsr),
+
+RISCV_IMPLIED_EXTS_RULE_END
+},
+};
+
+static RISCVCPUImpliedExtsRule RVM_IMPLIED = {
+.is_misa = true,
+.ext = RVM,
+.implied_exts = {
+CPU_CFG_OFFSET(ext_zmmul),
+
+RISCV_IMPLIED_EXTS_RULE_END
+},
+};
+
+static RISCVCPUImpliedExtsRule RVV_IMPLIED = {
+.is_misa = true,
+.ext = RVV,
+.implied_exts = {
+CPU_CFG_OFFSET(ext_zve64d),
+
+RISCV_IMPLIED_EXTS_RULE_END
+},
+};
+
 RISCVCPUImpliedExtsRule *riscv_misa_implied_rules[] = {
-NULL
+_IMPLIED, _IMPLIED, _IMPLIED,
+_IMPLIED, _IMPLIED, NULL
 };
 
 RISCVCPUImpliedExtsRule *riscv_ext_implied_rules[] = {
-- 
2.43.2

Re: [PATCH 2/6] target/riscv: Introduce extension implied rule helpers

[Frank Chang]

 於 2024年6月3日 週一 下午2:06寫道：
>
> From: Frank Chang 
>
> Introduce helpers to enable the extensions based on the implied rules.
> The implied extensions are enabled recursively, so we don't have to
> expand all of them manually. This also eliminates the old-fashioned
> ordering requirement. For example, Zvksg implies Zvks, Zvks implies
> Zvksed, etc., removing the need to check the implied rules of Zvksg
> before Zvks.
>
> Signed-off-by: Frank Chang 
> Reviewed-by: Jerry Zhang Jian 
> ---
>  target/riscv/tcg/tcg-cpu.c | 84 ++
>  1 file changed, 84 insertions(+)
>
> diff --git a/target/riscv/tcg/tcg-cpu.c b/target/riscv/tcg/tcg-cpu.c
> index 683f604d9f..243a8547a2 100644
> --- a/target/riscv/tcg/tcg-cpu.c
> +++ b/target/riscv/tcg/tcg-cpu.c
> @@ -36,6 +36,9 @@
>  static GHashTable *multi_ext_user_opts;
>  static GHashTable *misa_ext_user_opts;
>
> +static GHashTable *misa_implied_rules;
> +static GHashTable *ext_implied_rules;
> +
>  static bool cpu_cfg_ext_is_user_set(uint32_t ext_offset)
>  {
>  return g_hash_table_contains(multi_ext_user_opts,
> @@ -833,11 +836,90 @@ static void riscv_cpu_validate_profiles(RISCVCPU *cpu)
>  }
>  }
>
> +static void riscv_cpu_init_implied_exts_rules(void)
> +{
> +RISCVCPUImpliedExtsRule *rule;
> +int i;
> +
> +for (i = 0; (rule = riscv_misa_implied_rules[i]); i++) {
> +g_hash_table_insert(misa_implied_rules, GUINT_TO_POINTER(rule->ext),
> +(gpointer)rule);
> +}
> +
> +for (i = 0; (rule = riscv_ext_implied_rules[i]); i++) {
> +g_hash_table_insert(ext_implied_rules, GUINT_TO_POINTER(rule->ext),
> +(gpointer)rule);
> +}
> +}
> +
> +static void cpu_enable_implied_rule(RISCVCPU *cpu,
> +RISCVCPUImpliedExtsRule *rule)
> +{
> +CPURISCVState *env = >env;
> +RISCVCPUImpliedExtsRule *ir;
> +int i;
> +
> +if (!rule->enabled) {

Sorry that I found that the rule is not properly applied to the
secondary cores when SMP > 1.
I will fix the issue and resend the patchset.

Regards,
Frank Chang

> +/* Enable the implied MISAs. */
> +if (rule->implied_misas) {
> +riscv_cpu_set_misa_ext(env, env->misa_ext | rule->implied_misas);
> +
> +for (i = 0; misa_bits[i] != 0; i++) {
> +if (rule->implied_misas & misa_bits[i]) {
> +ir = g_hash_table_lookup(misa_implied_rules,
> + GUINT_TO_POINTER(misa_bits[i]));
> +
> +if (ir) {
> +cpu_enable_implied_rule(cpu, ir);
> +}
> +}
> +}
> +}
> +
> +/* Enable the implied extensions. */
> +for (i = 0; rule->implied_exts[i] != RISCV_IMPLIED_EXTS_RULE_END; 
> i++) {
> +cpu_cfg_ext_auto_update(cpu, rule->implied_exts[i], true);
> +
> +ir = g_hash_table_lookup(ext_implied_rules,
> + 
> GUINT_TO_POINTER(rule->implied_exts[i]));
> +
> +if (ir) {
> +cpu_enable_implied_rule(cpu, ir);
> +}
> +}
> +
> +rule->enabled = true;
> +}
> +}
> +
> +static void riscv_cpu_enable_implied_rules(RISCVCPU *cpu)
> +{
> +RISCVCPUImpliedExtsRule *rule;
> +int i;
> +
> +/* Enable the implied MISAs. */
> +for (i = 0; (rule = riscv_misa_implied_rules[i]); i++) {
> +if (riscv_has_ext(>env, rule->ext)) {
> +cpu_enable_implied_rule(cpu, rule);
> +}
> +}
> +
> +/* Enable the implied extensions. */
> +for (i = 0; (rule = riscv_ext_implied_rules[i]); i++) {
> +if (isa_ext_is_enabled(cpu, rule->ext)) {
> +cpu_enable_implied_rule(cpu, rule);
> +}
> +}
> +}
> +
>  void riscv_tcg_cpu_finalize_features(RISCVCPU *cpu, Error **errp)
>  {
>  CPURISCVState *env = >env;
>  Error *local_err = NULL;
>
> +riscv_cpu_init_implied_exts_rules();
> +riscv_cpu_enable_implied_rules(cpu);
> +
>  riscv_cpu_validate_misa_priv(env, _err);
>  if (local_err != NULL) {
>  error_propagate(errp, local_err);
> @@ -1343,6 +1425,8 @@ static void riscv_tcg_cpu_instance_init(CPUState *cs)
>
>  misa_ext_user_opts = g_hash_table_new(NULL, g_direct_equal);
>  multi_ext_user_opts = g_hash_table_new(NULL, g_direct_equal);
> +misa_implied_rules = g_hash_table_new(NULL, g_direct_equal);
> +ext_implied_rules = g_hash_table_new(NULL, g_direct_equal);
>  riscv_cpu_add_user_properties(obj);
>
>  if (riscv_cpu_has_max_extensions(obj)) {
> --
> 2.43.2
>
>

Re: [tor-relays] Relay migration

[Frank Lý via tor-relays]

Keep the same Tor identity keys.

Frank

Jun 4, 2024, 9:56 AM by tor-relays@lists.torproject.org:

> Hello everyone.
> I have to move somewhere else a a (middle) relay I have been running for a few
> years. It will be down for 2-4 weeks, then be back online in a different
> location, with different ISP, at better speed. But it will run on the same
> hardware and software. Should I keep the same keys, or start from scratch?
>
>
> --
> Eldalië
> My private key is attached. Please, use it and provide me yours!
> ___
> tor-relays mailing list
> tor-relays@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
>

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [FRIAM] St John's Coffee Shop Open This Friday

[Frank Wimberly]

George has been told that the coffee shop at St John's will be open this
Friday.  Let's plan to meet there unless we hear otherwise before then.

Frank

---
Frank C. Wimberly
140 Calle Ojo Feliz,
Santa Fe, NM 87505

505 670-9918
Santa Fe, NM

On Mon, Jun 3, 2024, 9:42 AM George Duncan  wrote:

> I called and they said they will be open this Friday. With construction,
> one week at a time.
>
> George Duncan
> Emeritus Professor of Statistics, Carnegie Mellon University
> georgeduncanart.com
> See posts on Facebook, Twitter, and Instagram
> Land: (505) 983-6895
> Mobile: (505) 469-4671
>
> My art theme: Dynamic exposition of the tension between matrix order and
> luminous chaos.
>
> "Attempt what is not certain. Certainty may or may not come later. It may
> then be a valuable delusion."
> From "Notes to myself on beginning a painting" by Richard Diebenkorn.
>
> "It's that knife-edge of uncertainty where we come alive to our truest
> power." Joanna Macy.
>
>
>
-. --- - / ...- .- .-.. .. -.. / -- --- .-. ... . / -.-. --- -.. .
FRIAM Applied Complexity Group listserv
Fridays 9a-12p Friday St. Johns Cafe   /   Thursdays 9a-12p Zoom 
https://bit.ly/virtualfriam
to (un)subscribe http://redfish.com/mailman/listinfo/friam_redfish.com
FRIAM-COMIC http://friam-comic.blogspot.com/
archives:  5/2017 thru present https://redfish.com/pipermail/friam_redfish.com/
  1/2003 thru 6/2021  http://friam.383.s1.nabble.com/

Re: F35 Change: Debuginfod By Default (Self-Contained Change proposal)

[Frank Ch. Eigler]

Hi, Denys -


dvlasenk wrote:

> [...]
> Now readelf, annobin and hell knows what else started to talk to
> REMOTE SERVERS, deep out of internals of complicated build infrastructure
> running on presumably secure build machines of various IT corporations
> and whatnot!

(It may not be appropriate for secure build machines to have general
internet access, but that's for the operators to decide.)

> [...] Do you understand how many fetches of debuginfo will be
> attempted by e.g.  a kernel build tooling when it runs readelf on 8000
> freshly built modules _for every kernel build_? How slow it is?

If remote debuginfo is not needed for these particular readelf
invocations, then the tools should not be making debuginfod calls.
Can you help identify examples?

> Now various tools need to forcibly unset the variable to stop this madness.

The defaults are set with normal developers in mind.


- FChE
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

PATCH: debuginfod configury rework

[Frank Ch. Eigler]

Hi -

A few buildbots are unhappy with the debuginfod configury from
yesterday.  It's right: it's rather convoluted.  This patch
reworks and harmonizes all of that stuff.


Author: Frank Ch. Eigler 
Date:   Mon Jun 3 18:14:52 2024 -0400

rework debuginfod configury

Rework the top level configure.ac to systematize the
debuginfod-related checks, inferences, rejections,
and configuration outputs.

Tested by hand on a F39 machine, installing/uninstalling
the various dependencies one at a time, and rerunning
the configury with / without --enable-*debuginfod* flags.

Signed-off-by: Frank Ch. Eigler 

diff --git a/configure.ac b/configure.ac
index 836d61ea6c0d..ddea59525829 100644
--- a/configure.ac
+++ b/configure.ac
@@ -671,41 +671,6 @@ case "$ac_cv_search__obstack_free" in
 esac
 AC_SUBST([obstack_LIBS])
 
-enable_ima_verification="x"
-AC_CHECK_LIB(rpm, headerGet, [
-  AC_CHECK_DECL(RPMSIGTAG_FILESIGNATURES,
-  [
-enable_ima_verification=$enable_ima_verification"rpm"
-AC_SUBST(rpm_LIBS, '-lrpm -lrpmio')
-  ],
-  [], [#include ])
-])
-
-dnl we use only the header, not the code of this library
-AC_CHECK_HEADER(imaevm.h, [
-  enable_ima_verification=$enable_ima_verification"imaevm"
-])
-
-AC_CHECK_LIB(crypto, EVP_MD_CTX_new, [
-  enable_ima_verification=$enable_ima_verification"crypto"
-  AC_SUBST(crypto_LIBS, '-lcrypto')
-])
-
-AC_ARG_ENABLE(debuginfod-ima-verification,
- [AS_HELP_STRING([--enable-debuginfod-ima-verification],[enable 
per-file signature verification])],
- [want_ima_verification=$enableval],[want_ima_verification=auto])
-
-debuginfod_ima_verification_enabled="no"
-if test "x$want_ima_verification" = "xno"; then
-  enable_ima_verification=nope # indicate failure of prerequisites for 
AM_CONDITIONAL below
-elif test "$enable_ima_verification" = "xrpmimaevmcrypto"; then
-  debuginfod_ima_verification_enabled="yes"
-  AC_DEFINE([ENABLE_IMA_VERIFICATION], [1], [Define if the required ima 
verification libraries are available])
-elif test "x$want_ima_verification" = "xyes"; then
-  AC_MSG_ERROR("missing prerequisites for ima verification")
-fi
-AM_CONDITIONAL([ENABLE_IMA_VERIFICATION],[test "$enable_ima_verification" = 
"xrpmimaevmcrypto"])
-
 dnl The directories with content.
 
 dnl Documentation.
@@ -855,53 +820,71 @@ AX_CXX_COMPILE_STDCXX(11, noext, optional)
 AS_IF([test "x$HAVE_CXX11" = "x1"], [HAVE_CXX11=yes], [HAVE_CXX11=no])
 AM_CONDITIONAL([HAVE_CXX11],[test "x$HAVE_CXX11" = "xyes"])
 
-# Look for libcurl for libdebuginfod minimum version as per rhel7.
-AC_ARG_ENABLE([libdebuginfod],AS_HELP_STRING([--enable-libdebuginfod], [Build 
debuginfod client library (can be =dummy)]))
-AS_IF([test "x$enable_libdebuginfod" != "xno"], [
-if test "x$enable_libdebuginfod" != "xdummy"; then
-  AC_MSG_NOTICE([checking libdebuginfod dependencies, 
--disable-libdebuginfod or --enable-libdebuginfo=dummy to skip])
-  enable_libdebuginfod=yes # presume success
-  PKG_PROG_PKG_CONFIG
-  PKG_CHECK_MODULES([libcurl],[libcurl >= 
7.29.0],[],[enable_libdebuginfod=no])
-else
-  AC_MSG_NOTICE([building (bootstrap) dummy libdebuginfo library])
-fi
-])
-
-AC_CHECK_LIB(pthread, pthread_setname_np, [
-  AC_DEFINE([HAVE_PTHREAD_SETNAME_NP],[1],[Enable 
pthread_setname_np])])
-
-AS_IF([test "x$enable_libdebuginfod" = "xyes" || test "x$enable_libdebuginfod" 
= "xdummy"],
-  [AC_DEFINE([ENABLE_LIBDEBUGINFOD], [1], [Enable libdebuginfod])])
-AS_IF([test "x$enable_libdebuginfod" = "xdummy"],
-  [AC_DEFINE([DUMMY_LIBDEBUGINFOD], [1], [Build dummy libdebuginfod])])
-AM_CONDITIONAL([LIBDEBUGINFOD],[test "x$enable_libdebuginfod" = "xyes" || test 
"x$enable_libdebuginfod" = "xdummy"])
-AM_CONDITIONAL([DUMMY_LIBDEBUGINFOD],[test "x$enable_libdebuginfod" = 
"xdummy"])
 AC_CHECK_HEADERS([execinfo.h])
 
-# Look for libmicrohttpd, libarchive, sqlite for debuginfo server and srcfiles 
tool
-# minimum versions as per rhel7.
-AC_ARG_ENABLE([debuginfod],AS_HELP_STRING([--enable-debuginfod], [Build 
debuginfod server]))
-AS_IF([test "x$enable_debuginfod" != "xno"], [
-if test "x$HAVE_CXX11" = "xno"; then
-  AC_MSG_ERROR([the compiler does not support C++11, use 
--disable-debuginfod to disable.])
-fi
-AC_MSG_NOTICE([checking debuginfod dependencies, --disable-debuginfod to 
skip])
-if test "x$enable_libdebuginfod" = "xno"; then
-  AC_MSG_ERROR([need libdebuginfod (or dummy), use --disable-debuginfod to 
disable.])
-fi
-enable_debuginfod=yes # p

[FFmpeg-cvslog] lavc/vvc: Reallocate pixel buffers if pixel shift changes

[Frank Plowman]

ffmpeg | branch: master | Frank Plowman  | Mon Jun  3 
14:06:35 2024 +0100| [d866f49791c11f730ce3d277b16524220ca74f6d] | committer: 
Nuo Mi

lavc/vvc: Reallocate pixel buffers if pixel shift changes

Allocations in the following lines depend on the pixel shift, and so
these buffers must be reallocated if the pixel shift changes.  Patch
fixes segmentation faults in fuzzed bitstreams.

Signed-off-by: Frank Plowman 

> http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=d866f49791c11f730ce3d277b16524220ca74f6d
---

 libavcodec/vvc/dec.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/libavcodec/vvc/dec.c b/libavcodec/vvc/dec.c
index e53ad4e607..f5603306f3 100644
--- a/libavcodec/vvc/dec.c
+++ b/libavcodec/vvc/dec.c
@@ -214,7 +214,8 @@ static void pixel_buffer_nz_tl_init(TabList *l, 
VVCFrameContext *fc)
 const int c_end  = chroma_idc ? VVC_MAX_SAMPLE_ARRAYS : 1;
 const int changed= fc->tab.sz.chroma_format_idc != chroma_idc ||
 fc->tab.sz.width != width || fc->tab.sz.height != height ||
-fc->tab.sz.ctu_width != ctu_width || fc->tab.sz.ctu_height != 
ctu_height;
+fc->tab.sz.ctu_width != ctu_width || fc->tab.sz.ctu_height != 
ctu_height ||
+fc->tab.sz.pixel_shift != ps;
 
 tl_init(l, 0, changed);
 

___
ffmpeg-cvslog mailing list
ffmpeg-cvslog@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-cvslog

To unsubscribe, visit link above, or email
ffmpeg-cvslog-requ...@ffmpeg.org with subject "unsubscribe".

Re: [PATCH] selftests: drivers/s390x: Use SKIP() during FIXTURE_SETUP

[Janosch Frank]

On 5/18/24 02:18, Kees Cook wrote:

Instead of mixing selftest harness and ksft helpers, perform SKIP
testing from the FIXTURE_SETUPs. This also means TEST_HARNESS_MAIN does
not need to be open-coded.

Signed-off-by: Kees Cook 
---


Adding the author in CC.


This changes the skip behavior from one single skip to a skip per test.
Not an issue, but a change.

But also we're generating invalid TAP AFAIK which we also have been 
before but we can fix that in this patch.


From what I understand this line should have a "#" prefix to show that 
it's a comment:

Enable CONFIG_S390_UV_UAPI and check the access rights on /dev/uv.

Re: [PATCH 4/4] hw/net: Fix the transmission return size

[Frank Chang]

Reviewed-by: Frank Chang 

Fea.Wang  於 2024年6月3日 週一 下午1:48寫道：
>
> Fix the transmission return size because not all bytes could be
> transmitted successfully. So, return a successful length instead of a
> constant value.
>
> Signed-off-by: Fea.Wang 
> ---
>  hw/net/xilinx_axienet.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/hw/net/xilinx_axienet.c b/hw/net/xilinx_axienet.c
> index 7d1fd37b4a..05d41bd548 100644
> --- a/hw/net/xilinx_axienet.c
> +++ b/hw/net/xilinx_axienet.c
> @@ -847,7 +847,7 @@ static ssize_t eth_rx(NetClientState *nc, const uint8_t 
> *buf, size_t size)
>  axienet_eth_rx_notify(s);
>
>  enet_update_irq(s);
> -return size;
> +return s->rxpos;
>  }
>
>  static size_t
> --
> 2.34.1
>
>

Re: [PATCH 3/4] hw/dma: Add a trace log for a description loading failure

[Frank Chang]

Reviewed-by: Frank Chang 

Fea.Wang  於 2024年6月3日 週一 下午1:49寫道：
>
> Due to a description loading failure, adding a trace log makes observing
> the DMA behavior easy.
>
> Signed-off-by: Fea.Wang 
> ---
>  hw/dma/trace-events| 3 +++
>  hw/dma/xilinx_axidma.c | 3 +++
>  2 files changed, 6 insertions(+)
>
> diff --git a/hw/dma/trace-events b/hw/dma/trace-events
> index 3c47df54e4..95db083be4 100644
> --- a/hw/dma/trace-events
> +++ b/hw/dma/trace-events
> @@ -44,3 +44,6 @@ pl330_debug_exec_stall(void) "stall of debug instruction 
> not implemented"
>  pl330_iomem_write(uint32_t offset, uint32_t value) "addr: 0x%08"PRIx32" 
> data: 0x%08"PRIx32
>  pl330_iomem_write_clr(int i) "event interrupt lowered %d"
>  pl330_iomem_read(uint32_t addr, uint32_t data) "addr: 0x%08"PRIx32" data: 
> 0x%08"PRIx32
> +
> +# xilinx_axidma.c
> +xilinx_axidma_loading_desc_fail(uint32_t res) "error:%d"
> diff --git a/hw/dma/xilinx_axidma.c b/hw/dma/xilinx_axidma.c
> index b8ab5a423d..1bbb9d6c4c 100644
> --- a/hw/dma/xilinx_axidma.c
> +++ b/hw/dma/xilinx_axidma.c
> @@ -36,6 +36,7 @@
>  #include "sysemu/dma.h"
>  #include "hw/stream.h"
>  #include "qom/object.h"
> +#include "trace.h"
>
>  #define D(x)
>
> @@ -200,6 +201,8 @@ static MemTxResult stream_desc_load(struct Stream *s, 
> hwaddr addr)
>  addr, MEMTXATTRS_UNSPECIFIED,
>  d, sizeof *d);
>  if (result != MEMTX_OK) {
> +trace_xilinx_axidma_loading_desc_fail(result);
> +
>  s->regs[R_DMACR] &= ~DMACR_RUNSTOP;
>  s->regs[R_DMASR] |= DMASR_HALTED;
>  s->regs[R_DMASR] |= DMASR_SLVERR;
> --
> 2.34.1
>
>

Re: [PATCH 2/4] hw/dma: Break the loop when loading descriptions fails

[Frank Chang]

Reviewed-by: Frank Chang 

Fea.Wang  於 2024年6月3日 週一 下午1:48寫道：
>
> When calling the loading a description function, it should be noticed
> that the function may return a failure value. Breaking the loop is one
> of the possible ways to handle it.
>
> Signed-off-by: Fea.Wang 
> ---
>  hw/dma/xilinx_axidma.c | 8 ++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/hw/dma/xilinx_axidma.c b/hw/dma/xilinx_axidma.c
> index 4b475e5484..b8ab5a423d 100644
> --- a/hw/dma/xilinx_axidma.c
> +++ b/hw/dma/xilinx_axidma.c
> @@ -291,7 +291,9 @@ static void stream_process_mem2s(struct Stream *s, 
> StreamSink *tx_data_dev,
>  }
>
>  while (1) {
> -stream_desc_load(s, s->regs[R_CURDESC]);
> +if (MEMTX_OK != stream_desc_load(s, s->regs[R_CURDESC])) {
> +break;
> +}
>
>  if (s->desc.status & SDESC_STATUS_COMPLETE) {
>  s->regs[R_DMASR] |= DMASR_HALTED;
> @@ -348,7 +350,9 @@ static size_t stream_process_s2mem(struct Stream *s, 
> unsigned char *buf,
>  }
>
>  while (len) {
> -stream_desc_load(s, s->regs[R_CURDESC]);
> +if (MEMTX_OK != stream_desc_load(s, s->regs[R_CURDESC])) {
> +break;
> +}
>
>  if (s->desc.status & SDESC_STATUS_COMPLETE) {
>  s->regs[R_DMASR] |= DMASR_HALTED;
> --
> 2.34.1
>
>

Re: [PATCH 1/4] hw/dma: Enhance error handling in loading description

[Frank Chang]

Reviewed-by: Frank Chang 

Fea.Wang  於 2024年6月3日 週一 下午1:48寫道：
>
> Loading a description from memory may cause a bus-error. In this
> case, the DMA should stop working, set the error flag, and return
> the error value.
>
> Signed-off-by: Fea.Wang 
> ---
>  hw/dma/xilinx_axidma.c | 16 ++--
>  1 file changed, 14 insertions(+), 2 deletions(-)
>
> diff --git a/hw/dma/xilinx_axidma.c b/hw/dma/xilinx_axidma.c
> index 0ae056ed06..4b475e5484 100644
> --- a/hw/dma/xilinx_axidma.c
> +++ b/hw/dma/xilinx_axidma.c
> @@ -71,8 +71,10 @@ enum {
>  enum {
>  DMASR_HALTED = 1,
>  DMASR_IDLE  = 2,
> +DMASR_SLVERR = 1 << 5,
>  DMASR_IOC_IRQ  = 1 << 12,
>  DMASR_DLY_IRQ  = 1 << 13,
> +DMASR_ERR_IRQ  = 1 << 14,
>
>  DMASR_IRQ_MASK = 7 << 12
>  };
> @@ -190,17 +192,27 @@ static inline int streamid_from_addr(hwaddr addr)
>  return sid;
>  }
>
> -static void stream_desc_load(struct Stream *s, hwaddr addr)
> +static MemTxResult stream_desc_load(struct Stream *s, hwaddr addr)
>  {
>  struct SDesc *d = >desc;
>
> -address_space_read(>dma->as, addr, MEMTXATTRS_UNSPECIFIED, d, sizeof 
> *d);
> +MemTxResult result = address_space_read(>dma->as,
> +addr, MEMTXATTRS_UNSPECIFIED,
> +d, sizeof *d);
> +if (result != MEMTX_OK) {
> +s->regs[R_DMACR] &= ~DMACR_RUNSTOP;
> +s->regs[R_DMASR] |= DMASR_HALTED;
> +s->regs[R_DMASR] |= DMASR_SLVERR;
> +s->regs[R_DMASR] |= DMASR_ERR_IRQ;
> +return result;
> +}
>
>  /* Convert from LE into host endianness.  */
>  d->buffer_address = le64_to_cpu(d->buffer_address);
>  d->nxtdesc = le64_to_cpu(d->nxtdesc);
>  d->control = le32_to_cpu(d->control);
>  d->status = le32_to_cpu(d->status);
> +return result;
>  }
>
>  static void stream_desc_store(struct Stream *s, hwaddr addr)
> --
> 2.34.1
>
>

[PATCH] drm/amdgpu: Update soc24_enum.h and soc21_enum.h

[Min, Frank]

[AMD Official Use Only - AMD Internal Distribution Only]


From: Frank Min mailto:frank@amd.com>>



Update to latest changes.



Signed-off-by: Frank Min mailto:frank@amd.com>>

---

drivers/gpu/drm/amd/include/soc21_enum.h | 2 +-  
drivers/gpu/drm/amd/include/soc24_enum.h | 2 +-

2 files changed, 2 insertions(+), 2 deletions(-)



diff --git a/drivers/gpu/drm/amd/include/soc21_enum.h 
b/drivers/gpu/drm/amd/include/soc21_enum.h

index 951ec2900c61..07d98bff7f73 100644

--- a/drivers/gpu/drm/amd/include/soc21_enum.h

+++ b/drivers/gpu/drm/amd/include/soc21_enum.h

@@ -92,7 +92,7 @@ DSM_SINGLE_WRITE_EN  = 0x0001,

  */

 typedef enum ENUM_NUM_SIMD_PER_CU {

-NUM_SIMD_PER_CU  = 0x0004,

+NUM_SIMD_PER_CU  = 0x0002,

} ENUM_NUM_SIMD_PER_CU;

 /*

diff --git a/drivers/gpu/drm/amd/include/soc24_enum.h 
b/drivers/gpu/drm/amd/include/soc24_enum.h

index c47b8cc2f203..3eb7662bbbda 100644

--- a/drivers/gpu/drm/amd/include/soc24_enum.h

+++ b/drivers/gpu/drm/amd/include/soc24_enum.h

@@ -73,7 +73,7 @@ CP_PERFMON_STATE_COUNT_AND_DUMP_PHANTOM  = 0x0005,

  */

 typedef enum ENUM_NUM_SIMD_PER_CU {

-NUM_SIMD_PER_CU  = 0x0004,

+NUM_SIMD_PER_CU  = 0x0002,

} ENUM_NUM_SIMD_PER_CU;

 /*

--

2.34.1

Re: [gentoo-user] Mobo, CPU, memory and a m.2 thingy. This work together?

[Frank Steinmetzger]

Am Sun, Jun 02, 2024 at 08:27:57AM -0500 schrieb Dale:

> I thought of something on the m.2 thing.  I plan to put my OS on it.  I
> usually use tmpfs and compile in memory anyway but do have some set to
> use spinning rust. Once I get 128GB installed, I should be able to do
> that with all packages anyway but still, I had a question.  Should I put
> the portage work directory on a spinning rust drive to save wear and
> tear on the SSD or have they got to the point now that doesn't matter
> anymore?  I know all the SSD devices have improved a lot since the first
> ones came out. 

We’ve had this topic before. You can do some archaeology with dumpe2fs and 
extrapolate:

$ dumpe2fs -h /dev/mapper/vg-root
...
Filesystem created:   Sun Apr 17 16:47:03 2022
...
Lifetime writes:  877 GB


So that’s around 900 GB in 2 years. This is an Arch system, so may not 
experience quite as many writes from updates (especially not from any 
on-disk emerging), but Arch does have its own share of volume-heavy 
upgrades. Just today, after being away on travel for 11 days, I had to 
download 2.5 GB and unpack over 8 GB of files.


My home partition has accumulated 2600 GB in the same time. Firstly, it’s 
200 GB in size vs. 45 GB for the root system. And secondly, sometimes the 
baloo file extractor runs amok and keeps writing gigabytes of index files. 
It’s an Evo 970 Plus 2 TB, so I just scratched its guaranteed lifetime write 
amount.

-- 
Grüße | Greetings | Salut | Qapla’
Please do not share anything from, with or about me on any social network.

We don’t put a single drop of alcohol on the table...
we pour very cautiously.


signature.asc
Description: PGP signature

Re: [gentoo-user] Mobo, CPU, memory and a m.2 thingy. This work together?

[Frank Steinmetzger]

Am Sun, Jun 02, 2024 at 12:38:13AM -0500 schrieb Dale:

> I'll also max the memory out too.  I'm
> unclear on the max memory tho.  One place shows 128GB, hence two 32GB
> sticks.  The out of stock Newegg one claims 256GB, which would be nice. 
> I'm not sure what to think on memory.  Anyway.  If the thing is fast
> enough, I may do the memory first then CPU later.  If I need a faster
> CPU, I may do it first then the memory.

One interesting fact: four sticks run slower than two sticks. I don’t 
remember the exact technical reason, but it is so. Two sticks can run at the 
maximum stock speed (i.e. without overclocking profiles, which is 5200 MT/s 
for the 7600X’s memory controller). But four sticks are clocked lower.

-- 
Grüße | Greetings | Salut | Qapla’
Please do not share anything from, with or about me on any social network.

It’s the same inside as it is outside, just different.


signature.asc
Description: PGP signature

Re: Backup resolver after X seconds

[Frank Cusack via Unbound-users]

How about pointing unbound to a local dnsmasq instance, configured to use
parallel upstreams?

https://serverfault.com/questions/732920/how-to-do-parallel-queries-to-the-upstream-dns-using-unbound

If you don't need some specific feature of unbound, you could just use
dnsmasq by itself.

On Mon, Jun 3, 2024 at 2:02 PM Scott Q.  wrote:

> Some apps have even longer and don't even try a backup resolver
>
> On Monday, 03/06/2024 at 15:57 Frank Cusack wrote:
>
> Sorry that this isn't actually an answer, but does it matter? What client
> has a 5s timeout before the client moves on to its own next resolver?
>
> On Mon, Jun 3, 2024 at 8:28 AM Scott Q. via Unbound-users <
> unbound-users@lists.nlnetlabs.nl> wrote:
>
>> Is there a way to configure within Unbound a backup resolver for all
>> queries that take over 5 seconds for example ?
>>
>> Aka, I'd like to forward to 8.8.8.8 all queries that I can't resolve for
>> whatever reason: network issues, firewalls, etc.
>>
>> For example: dig +trace 77.184.100.61.in-addr.arpa
>>
>> This sometimes takes 10 seconds to resolve, other times it times out
>> completely but 8.8.8.8 can return an answer within 1 second.
>>
>> I also don't want to implement a per-host/network/domain solution, I just
>> want to forward all queries that take longer than 5 seconds.
>>
>> Is it possible or is there an alternative ?
>>
>> Thank you
>>
>

Re: guile-ncurses unicode support

[Frank Terbeck]

conf, so this might not be the most idiomatic way of doing this.


In the meantime, the guix  build could just drop --without-ncursesw from
their build instructions to make this work: Guix's ncurses has wide-cha-
racter support and the default of  guile-ncurses is to test for this, so
it will succeed. A patch for that might look like this (untested):


diff --git a/gnu/packages/guile-xyz.scm b/gnu/packages/guile-xyz.scm
index 94417079c7..982b59efe7 100644
--- a/gnu/packages/guile-xyz.scm
+++ b/gnu/packages/guile-xyz.scm
@@ -2718,8 +2718,12 @@ (define-public guile-ncurses
   (guix build utils))
#:imported-modules ((guix build guile-build-system)
,@%gnu-build-system-modules)
-   #:configure-flags (list "--with-ncursesw" ; Unicode support
-   "--with-gnu-filesystem-hierarchy")
+   #:configure-flags (list
+  ;; This is currently commented out due to a bug
+  ;; in configure.ac of guile-ncurses, which makes
+  ;; this behave just like --without-ncurses.
+  ;;"--with-ncursesw" ; Unicode support
+  "--with-gnu-filesystem-hierarchy")
#:phases
(modify-phases %standard-phases
  (add-before 'build 'fix-libguile-ncurses-file-name


Regards, Frank

Re: [FRIAM] Objective Reality Doesn’t Exist. We’ve Known This for a Century. It’s Time to Embrace It and Move On. | by Casper Wilstrup | Machine Consciousness | Medium

[Frank Wimberly]

This is the article I had in mind

https://www.huffpost.com/entry/why-gen-z-wont-show-their-feet_l_64cd1b52e4b01796c06c0cc4


---
Frank C. Wimberly
140 Calle Ojo Feliz,
Santa Fe, NM 87505

505 670-9918
Santa Fe, NM

On Fri, May 31, 2024, 9:34 AM Frank Wimberly  wrote:

> It exists in my mind.  Joke.
>
> ---
> Frank C. Wimberly
> 140 Calle Ojo Feliz,
> Santa Fe, NM 87505
>
> 505 670-9918
> Santa Fe, NM
>
> On Fri, May 31, 2024, 8:59 AM Nicholas Thompson 
> wrote:
>
>> This (see below) got served up to me out of the blue this morning.  The
>> way it's put here, Frank and Bruce might actually agree with it.  Still,
>> it's straight Peirce.  I have no idea who the author is; do any of you?
>>
>> Here's crucial passage.
>>
>> *Our understanding of reality needs a complete overhaul. Rather than
>> viewing it as a fixed, external stage upon which events play out, we should
>> consider it as a dynamic interplay between observers and their
>> environment [*experiences*]. Reality, in this view, doesn’t reside out
>> there, independent of us. Instead, reality is our interactions with the
>> world  [*one another*], shaped and defined by our observations [*
>> experiences*]. Reality is nothing but [*the telos of*] those
>> interactions between subjects.*
>>
>> I had to make those little changes because the author,  like so many
>> aspiring monists, after arguing against observer independence for a hundred
>> words, slips up by implying that the "environment" is anything but
>> something else that we have to agree upon, if we are ever going to get on
>> with life.
>>
>> By the way,  I stipulate that nothing in his argument has ANYTHING to do
>> with quantum mechanics. The argument would be sound even if the idea of a
>> quantum had never been thought.  However, I like the idea of physics as
>> some kind of language of convergent belief.
>>
>> By the way,  In history there seem to have been two ways for people
>> converge on a common experience, charisma and democracy.  In charisma, we
>> pick some idiot (usually a psychopath) and share his or her experience.  In
>> democracy, we find  some way to blend our experiences into a common view.
>> Sometime in the next few months we will decide which way we want to go.
>>  Do we want to assign Trump the job of determining our common reality, or
>> do we want to continue to work it out amongst ourselves through experiment
>> and argument.
>>
>> Weather gorgeous here in the mosquito infested swamp.  Garden thriving.
>> A much better year.
>>
>> Watch that dry line in TX.  It's truly amazing.  Can it really be true
>> that I am the only weather fanatic on a list that is devoted to
>> complexity?   How can that be?
>>
>> NIck
>>
>>
>>
>>
>> https://medium.com/machine-cognition/objective-reality-doesnt-exist-it-is-time-to-accept-it-and-move-on-7524b494d6af
>>
>> <https://medium.com/machine-cognition/objective-reality-doesnt-exist-it-is-time-to-accept-it-and-move-on-7524b494d6af>
>> Objective Reality Doesn’t Exist: It is Time to Embrace it and Move On
>> <https://medium.com/machine-cognition/objective-reality-doesnt-exist-it-is-time-to-accept-it-and-move-on-7524b494d6af>
>> The shift towards a unified, observer-dependent reality forces us to let
>> go — once and for all — of the idea of objective reality
>> medium.com
>>
>>
>>
>> -. --- - / ...- .- .-.. .. -.. / -- --- .-. ... . / -.-. --- -.. .
>> FRIAM Applied Complexity Group listserv
>> Fridays 9a-12p Friday St. Johns Cafe   /   Thursdays 9a-12p Zoom
>> https://bit.ly/virtualfriam
>> to (un)subscribe http://redfish.com/mailman/listinfo/friam_redfish.com
>> FRIAM-COMIC http://friam-comic.blogspot.com/
>> archives:  5/2017 thru present
>> https://redfish.com/pipermail/friam_redfish.com/
>>   1/2003 thru 6/2021  http://friam.383.s1.nabble.com/
>>
>
-. --- - / ...- .- .-.. .. -.. / -- --- .-. ... . / -.-. --- -.. .
FRIAM Applied Complexity Group listserv
Fridays 9a-12p Friday St. Johns Cafe   /   Thursdays 9a-12p Zoom 
https://bit.ly/virtualfriam
to (un)subscribe http://redfish.com/mailman/listinfo/friam_redfish.com
FRIAM-COMIC http://friam-comic.blogspot.com/
archives:  5/2017 thru present https://redfish.com/pipermail/friam_redfish.com/
  1/2003 thru 6/2021  http://friam.383.s1.nabble.com/

Re: [FRIAM] Objective Reality Doesn’t Exist. We’ve Known This for a Century. It’s Time to Embrace It and Move On. | by Casper Wilstrup | Machine Consciousness | Medium

[Frank Wimberly]

You have Gen Z friends?  According to the NYT they won't let you see their
bare feet.

https://www.nytimes.com/2024/04/01/style/open-toe-sandal-appropriate.html

---
Frank C. Wimberly
140 Calle Ojo Feliz,
Santa Fe, NM 87505

505 670-9918
Santa Fe, NM

On Mon, Jun 3, 2024, 12:34 PM glen  wrote:

> IDK. Were we to allow that
>
> a) X merely means a singular, mostly atomic, thing, and
> b) "determine" means what most of us think it means,
>
> then you'd be right. A better way to state it would be:
>
> In the US, our collection of mechanisms for selecting the most powerful,
> but not all-powerful, person in our federa[l|ated] and hierarchically
> composed government carries too much structural/systemic bias for a
> reasonable person to describe it as "democratic". Nick's gloss was way too
> vague for one to use that more refined statement to contradict his. If we
> allow democracy to be a spectrum, some more, some less, democratic, then
> Nick's statement stands well enough. But as my Gen Z friends are telling me
> on a daily basis, they're not going to vote in November because it doesn't
> matter. Biden and Trump are the same person. Both lie. And even if/when
> they're not lying, whatever they intend to do will be subverted by or
> enervated with the noxious intentions of the oligarchs or self-aggrandizing
> agendas of the rest of the politicians, including SCOTUS.
>
> But even that sentiment (that the whole system is Borked) contradicts one
> of the normal interpretations of the word "determined". Such a frothing
> mess my be deterministic. But if it is, it's chaotic; so much so that
> morons like Trump wouldn't be capable of "determining our common reality".
> And even if we broaden the conception of "determine" out to mean something
> Rawlsian like the veil of ignorance, that which of Trump or Biden is
> elected will (or not) somehow affect the power status on the other side of
> the veil, my Gen Z friends would say it does not. The Musks and Thiels will
> still be the most powerful people on the planet come next year, regardless
> of who is elected. So neither Biden nor Trump "determine" our common
> reality in any meaningful sense, though they may well add a tiny little
> bias in some very large space.
>
>
> On 6/1/24 08:28, Prof David West wrote:
> > Nick said,
> >
> > /"In democracy, we find  some way to blend our experiences into a common
> view."/
> >
> > If the "democracy" of which you speak is that of the New England Town
> Hall, or that of tribal societies of long ago, you are probably reasonably
> accurate.
> >
> > However, that sense of "democracy" no longer exists, at least here in
> the US. Regardless of how one votes, the result is absolutely and
> completely *assigning   X   the job of determining our common reality*.
> >
> > davew
> >
> > On Fri, May 31, 2024, at 9:58 AM, Nicholas Thompson wrote:
> >> This (see below) got served up to me out of the blue this morning.  The
> way it's put here, Frank and Bruce might actually agree with it.  Still,
> it's straight Peirce.  I have no idea who the author is; do any of you?
> >>
> >> Here's crucial passage.
> >>
> >> /Our understanding of reality needs a complete overhaul. Rather than
> viewing it as a fixed, external stage upon which events play out, we should
> consider it as a dynamic interplay between observers and their
> environment [/experiences/]. Reality, in this view, doesn’t reside out
> there, independent of us. Instead, reality is our interactions with the
> world  [/one another/], shaped and defined by our
> observations [/experiences/]. Reality is nothing but [/the telos of/] those
> interactions between subjects./
> >>
> >> I had to make those little changes because the author,  like so many
> aspiring monists, after arguing against observer independence for a hundred
> words, slips up by implying that the "environment" is anything but
> something else that we have to agree upon, if we are ever going to get on
> with life.
> >>
> >> By the way,  I stipulate that nothing in his argument has ANYTHING to
> do with quantum mechanics. The argument would be sound even if the idea of
> a quantum had never been thought.  However, I like the idea of physics as
> some kind of language of convergent belief.
> >>
> >> By the way,  In history there seem to have been two ways for people
> converge on a common experience, charisma and democracy.  In charisma, we
> pick some idiot (usually a psychopath) and share his or her experience.  In
> democracy, we find  some way to blend our experiences into a common v

Re: Backup resolver after X seconds

[Frank Cusack via Unbound-users]

Sorry that this isn't actually an answer, but does it matter? What client
has a 5s timeout before the client moves on to its own next resolver?

On Mon, Jun 3, 2024 at 8:28 AM Scott Q. via Unbound-users <
unbound-users@lists.nlnetlabs.nl> wrote:

> Is there a way to configure within Unbound a backup resolver for all
> queries that take over 5 seconds for example ?
>
> Aka, I'd like to forward to 8.8.8.8 all queries that I can't resolve for
> whatever reason: network issues, firewalls, etc.
>
> For example: dig +trace 77.184.100.61.in-addr.arpa
>
> This sometimes takes 10 seconds to resolve, other times it times out
> completely but 8.8.8.8 can return an answer within 1 second.
>
> I also don't want to implement a per-host/network/domain solution, I just
> want to forward all queries that take longer than 5 seconds.
>
> Is it possible or is there an alternative ?
>
> Thank you
>

[Bug 2062556] Re: [Ubuntu-24.04] Hugepage memory is not getting released even after destroying the guest!

[Frank Heimes]

** Changed in: linux (Ubuntu)
   Status: Fix Committed => Fix Released

** Changed in: ubuntu-power-systems
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2062556

Title:
  [Ubuntu-24.04] Hugepage memory is not getting released even after
  destroying the guest!

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-power-systems/+bug/2062556/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

RE: [PATCH] drm/amdgpu: Set PTE_IS_PTE bit for gfx12

[Min, Frank]

[AMD Official Use Only - AMD Internal Distribution Only]

From: Frank Min 

Set PTE_IS_PTE bit while PRT is enabled on gfx12.

Signed-off-by: Frank Min 
---
 drivers/gpu/drm/amd/amdgpu/gmc_v12_0.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v12_0.c 
b/drivers/gpu/drm/amd/amdgpu/gmc_v12_0.c
index 7d99fcc58baf..e09be1a6c7d9 100644
--- a/drivers/gpu/drm/amd/amdgpu/gmc_v12_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gmc_v12_0.c
@@ -512,6 +512,7 @@ static void gmc_v12_0_get_vm_pte(struct amdgpu_device *adev,
*flags |= AMDGPU_PTE_PRT_GFX12;
*flags |= AMDGPU_PTE_SNOOPED;
*flags |= AMDGPU_PTE_SYSTEM;
+   *flags |= AMDGPU_PTE_IS_PTE;
*flags &= ~AMDGPU_PTE_VALID;
}

--
2.34.1

Re: [PATCH v4 05/12] dmaengine: Add STM32 DMA3 support

[Frank Li]

On Mon, Jun 03, 2024 at 10:09:36AM +0200, Amelie Delaunay wrote:
> On 5/31/24 22:21, Frank Li wrote:
> > On Fri, May 31, 2024 at 05:07:05PM +0200, Amelie Delaunay wrote:
> > > STM32 DMA3 driver supports the 3 hardware configurations of the STM32 DMA3
> > > controller:
> > > - LPDMA (Low Power): 4 channels, no FIFO
> > > - GPDMA (General Purpose): 16 channels, FIFO from 8 to 32 bytes
> > > - HPDMA (High Performance): 16 channels, FIFO from 8 to 256 bytes
> > > Hardware configuration of the channels is retrieved from the hardware
> > > configuration registers.
> > > 
> > > The client can specify its channel requirements through device tree.
> > > STM32 DMA3 channels can be individually reserved either because they are
> > > secure, or dedicated to another CPU.
> > > Indeed, channels availability depends on Resource Isolation Framework
> > > (RIF) configuration. RIF grants access to buses with Compartment ID (CID)
> > > filtering, secure and privilege level. It also assigns DMA channels to one
> > > or several processors.
> > > DMA channels used by Linux should be CID-filtered and statically assigned
> > > to CID1 or shared with other CPUs but using semaphore. In case CID
> > > filtering is not configured, dma-channel-mask property can be used to
> > > specify available DMA channels to the kernel, otherwise such channels
> > > will be marked as reserved and can't be used by Linux.
> > > 
> > > STM32 DMA3 is a new STM32 DMA controller, not a new version of an existing
> > > one.
> > > stm32-dma is not considered for reuse because register layout is 
> > > completely
> > > different and doesn't rely on descriptors mechanism.
> > > stm32-mdma is based on descriptors mechanism but there are significant
> > > differences in register layout and descriptors structure.
> > > 
> > > Signed-off-by: Amelie Delaunay 
> > > ---
> > > v4:
> > > - align comments alignment in enum definition
> > > - use __packed for stm32_dma3_hwdesc structure
> > > - use generic dma_wmb() instead of __iowmb()
> > > v3:
> > > - fix typo in commit message (Compartment)
> > > - add a paragraph in commit message to explain why stm32-dma and 
> > > stm32-mdma
> > >are not reused
> > > - add explicit write memory barrier on the last descriptor initialization
> > > v2:
> > > - lowercase in hex values
> > > - compatible has been updated to st,stm32mp25-dma3 (SoC specific)
> > > ---
> > >   drivers/dma/stm32/Kconfig  |   10 +
> > >   drivers/dma/stm32/Makefile |1 +
> > >   drivers/dma/stm32/stm32-dma3.c | 1440 
> > >   3 files changed, 1451 insertions(+)
> > >   create mode 100644 drivers/dma/stm32/stm32-dma3.c
> > > 
> > > diff --git a/drivers/dma/stm32/Kconfig b/drivers/dma/stm32/Kconfig
> > > index b72ae1a4502f..4d8d8063133b 100644
> > > --- a/drivers/dma/stm32/Kconfig
> > > +++ b/drivers/dma/stm32/Kconfig
> > > @@ -34,4 +34,14 @@ config STM32_MDMA
> > > If you have a board based on STM32 SoC with such DMA 
> > > controller
> > > and want to use MDMA say Y here.
> > > +config STM32_DMA3
> > > + tristate "STMicroelectronics STM32 DMA3 support"
> > > + select DMA_ENGINE
> > > + select DMA_VIRTUAL_CHANNELS
> > > + help
> > > +   Enable support for the on-chip DMA3 controller on STMicroelectronics
> > > +   STM32 platforms.
> > > +   If you have a board based on STM32 SoC with such DMA3 controller
> > > +   and want to use DMA3, say Y here.
> > > +
> > >   endif
> > > diff --git a/drivers/dma/stm32/Makefile b/drivers/dma/stm32/Makefile
> > > index 663a3896a881..5082db4b4c1c 100644
> > > --- a/drivers/dma/stm32/Makefile
> > > +++ b/drivers/dma/stm32/Makefile
> > > @@ -2,3 +2,4 @@
> > >   obj-$(CONFIG_STM32_DMA) += stm32-dma.o
> > >   obj-$(CONFIG_STM32_DMAMUX) += stm32-dmamux.o
> > >   obj-$(CONFIG_STM32_MDMA) += stm32-mdma.o
> > > +obj-$(CONFIG_STM32_DMA3) += stm32-dma3.o
> > > diff --git a/drivers/dma/stm32/stm32-dma3.c 
> > > b/drivers/dma/stm32/stm32-dma3.c
> > > new file mode 100644
> > > index ..49886117d29b
> > > --- /dev/null
> > > +++ b/drivers/dma/stm32/stm32-dma3.c
> > > @@ -0,0 +1,1440 @@
> > > +// SPDX-License-Identifier: GPL-2.0-only
> > > +/*
> > > 

[FFmpeg-devel] [PATCH] lavc/vvc: Reallocate pixel buffers if pixel shift changes

[Frank Plowman]

Allocations in the following lines depend on the pixel shift, and so
these buffers must be reallocated if the pixel shift changes.  Patch
fixes segmentation faults in fuzzed bitstreams.

Signed-off-by: Frank Plowman 
---
 libavcodec/vvc/dec.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/libavcodec/vvc/dec.c b/libavcodec/vvc/dec.c
index e53ad4e607..f5603306f3 100644
--- a/libavcodec/vvc/dec.c
+++ b/libavcodec/vvc/dec.c
@@ -214,7 +214,8 @@ static void pixel_buffer_nz_tl_init(TabList *l, 
VVCFrameContext *fc)
 const int c_end  = chroma_idc ? VVC_MAX_SAMPLE_ARRAYS : 1;
 const int changed= fc->tab.sz.chroma_format_idc != chroma_idc ||
 fc->tab.sz.width != width || fc->tab.sz.height != height ||
-fc->tab.sz.ctu_width != ctu_width || fc->tab.sz.ctu_height != 
ctu_height;
+fc->tab.sz.ctu_width != ctu_width || fc->tab.sz.ctu_height != 
ctu_height ||
+fc->tab.sz.pixel_shift != ps;
 
 tl_init(l, 0, changed);
 
-- 
2.45.1

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[docker-dev] Best way to reload your credit clone card

[Frank Domm]

Credit card cloning refers to making an unauthorized copy of a credit card. 
This practice is also sometimes called skimming. Thieves copy information 
at a credit card terminal using an electronic device and transfer the data 
from the stolen card to a new card or rewrite an existing card with the 
information.
https://t.me/psychdelicmushroomhempdispensary
https://t.me/psychdelicmushroomhempdispensary
https://t.me/psychdelicmushroomhempdispensary

• HOW CREDIT CARD CLONING WORKS 
>From the perspective of the thieves, cloning can be a very effective way to 
obtain credit card information, because it does not require the physical 
credit card to be stolen. Instead, they simply use an electronic device to 
covertly scan the card's information and copy it into the device’s memory. 
The thieves can then access that information digitally, or else download 
the information onto a separate credit card that is already in their 
possession.
https://t.me/psychdelicmushroomhempdispensary
https://t.me/psychdelicmushroomhempdispensary

•CAN A CLONED CARD BE USED AT AN ATM?
   This cloned data can then be transferred to another card, creating a 
duplicate. If the criminal also has the card's PIN (personal identification 
number), they can use the cloned card to withdraw money from the 
cardholder's account at an ATM.
https://t.me/psychdelicmushroomhempdispensary
https://t.me/psychdelicmushroomhempdispensary
https://t.me/psychdelicmushroomhempdispensary

• HOW TO USE THE CLONED CARD'S AT THE ATM MACHINE :
Step 1: Insert ATM Card.
Step 2: Select the Language.
Step 3: Enter 4 Digit ATM Pin.
Step 4: Select Your Transaction.
Step 5: Select Your Account.
Step 6: Enter the Withdrawal Money(withdraw £500 every after 2 hours)
Step 7: Collect the Cash.
Step 8: Take a Printed Receipt.
https://t.me/psychdelicmushroomhempdispensary
https://t.me/psychdelicmushroomhempdispensary

Once the information is recorded it can be transferred onto the magnetic 
strip of a new card or can be used to overwrite data on an already stolen 
credit card. For cards that use a personal identification number (PIN) 
number in addition to a magnetic strip, such as debit cards, the PIN would 
need to be observed and recorded. This is sometimes difficult to 
accomplish, adding additional protection against having your card 
compromised.

https://t.me/psychdelicmushroomhempdispensary
https://t.me/psychdelicmushroomhempdispensary
https://t.me/psychdelicmushroomhempdispensary
Search Frequently Asked Questions. Skimming or cloning cards is when the 
details of your card from the magnetic strip are put onto a blank card and 
then the card is used without your knowledge or permission.

Tele Channel : https://t.me/psychdelicmushroomhempdispensary
 Sell Fullz info ssn dob dl Fresh And Good - Sell DL Scan Front, Back + SSN 
number USA-Cvv usa-uk-au-eu-inter


HELLO CLIENT MINE

Tele Channel : https://t.me/psychdelicmushroomhempdispensary

Fullz Info Store

PHOTO/SCANS DL
Canada SCANS DL
United Kingdom SCANS DL
United States SCANS DL
Germany SCANS DL
Italy SCANS DL

- Fullz info USA

Fullz info USA+SSN
Fullz info USA+DL
Fullz info USA+AN:RN
Fullz info USA+Credit Score
Fullz info ID Scan Front+back+ssn+selfie
Fullz info Business

- Fullz info CA

Fullz info CA+SIN

- Fullz info UK

Tele Channel : https://t.me/psychdelicmushroomhempdispensary
ALL KIND OF FULLZ
UK FULLZ WITH NIN ..
UK FULLZ RANDOM ...
UK FULLZ WITH BANK ( BARCLAYS , HSBC , NATIONWIDE )
UK FULLZ WITH MOBILE NETWORK PROVIDERS (O2 , EE , VODAFONE..)
UK FULLZ DEAD + PHONE PROVIDER
UK FULLZ WITH AGE RANGE ..
UK FULLZ WITH SPECIFIC DOOR..
UK FULLZ WITH VBV
ALL OF THEM ARE FRESH FULLZ DEAD AND NOT RESOLD.
Tele Channel : https://t.me/psychdelicmushroomhempdispensary

---There are also many countries listed below---

Fullz info Argentina https://t.me/psychdelicmushroomhempdispensary
Fullz info Marokko https://t.me/psychdelicmushroomhempdispensary
Fullz info Russia https://t.me/psychdelicmushroomhempdispensary
Fullz info Romania https://t.me/psychdelicmushroomhempdispensary
Fullz info Czechia https://t.me/psychdelicmushroomhempdispensary
Fullz info Greece https://t.me/psychdelicmushroomhempdispensary
Fullz info Hungary https://t.me/psychdelicmushroomhempdispensary
Fullz info Latvia https://t.me/psychdelicmushroomhempdispensary
Fullz info Lithuania https://t.me/psychdelicmushroomhempdispensary
Fullz info Switzerland https://t.me/psychdelicmushroomhempdispensary
Fullz info Cyprus https://t.me/psychdelicmushroomhempdispensary
Fullz info Estonia https://t.me/psychdelicmushroomhempdispensary
Fullz info Netherlands https://t.me/psychdelicmushroomhempdispensary
Fullz info Belgium https://t.me/psychdelicmushroomhempdispensary
Fullz info Norway https://t.me/psychdelicmushroomhempdispensary
Fullz info Sweden https://t.me/psychdelicmushroomhempdispensary
Fullz info Ireland https://t.me/psychdelicmushroomhempdispensary
Fullz info Danmark https://t.me/psychdelicmushroomhempdispensary
Fullz info Spain 

[docker-dev] Buy flipping credit clone card with lowest balance

[Frank Domm]

Credit card cloning refers to making an unauthorized copy of a credit card. 
This practice is also sometimes called skimming. Thieves copy information 
at a credit card terminal using an electronic device and transfer the data 
from the stolen card to a new card or rewrite an existing card with the 
information.
https://t.me/psychdelicmushroomhempdispensary
https://t.me/psychdelicmushroomhempdispensary
https://t.me/psychdelicmushroomhempdispensary

• HOW CREDIT CARD CLONING WORKS 
>From the perspective of the thieves, cloning can be a very effective way to 
obtain credit card information, because it does not require the physical 
credit card to be stolen. Instead, they simply use an electronic device to 
covertly scan the card's information and copy it into the device’s memory. 
The thieves can then access that information digitally, or else download 
the information onto a separate credit card that is already in their 
possession.
https://t.me/psychdelicmushroomhempdispensary
https://t.me/psychdelicmushroomhempdispensary

•CAN A CLONED CARD BE USED AT AN ATM?
   This cloned data can then be transferred to another card, creating a 
duplicate. If the criminal also has the card's PIN (personal identification 
number), they can use the cloned card to withdraw money from the 
cardholder's account at an ATM.
https://t.me/psychdelicmushroomhempdispensary
https://t.me/psychdelicmushroomhempdispensary
https://t.me/psychdelicmushroomhempdispensary

• HOW TO USE THE CLONED CARD'S AT THE ATM MACHINE :
Step 1: Insert ATM Card.
Step 2: Select the Language.
Step 3: Enter 4 Digit ATM Pin.
Step 4: Select Your Transaction.
Step 5: Select Your Account.
Step 6: Enter the Withdrawal Money(withdraw £500 every after 2 hours)
Step 7: Collect the Cash.
Step 8: Take a Printed Receipt.
https://t.me/psychdelicmushroomhempdispensary
https://t.me/psychdelicmushroomhempdispensary

Once the information is recorded it can be transferred onto the magnetic 
strip of a new card or can be used to overwrite data on an already stolen 
credit card. For cards that use a personal identification number (PIN) 
number in addition to a magnetic strip, such as debit cards, the PIN would 
need to be observed and recorded. This is sometimes difficult to 
accomplish, adding additional protection against having your card 
compromised.

https://t.me/psychdelicmushroomhempdispensary
https://t.me/psychdelicmushroomhempdispensary
https://t.me/psychdelicmushroomhempdispensary
Search Frequently Asked Questions. Skimming or cloning cards is when the 
details of your card from the magnetic strip are put onto a blank card and 
then the card is used without your knowledge or permission.

Tele Channel : https://t.me/psychdelicmushroomhempdispensary
 Sell Fullz info ssn dob dl Fresh And Good - Sell DL Scan Front, Back + SSN 
number USA-Cvv usa-uk-au-eu-inter


HELLO CLIENT MINE

Tele Channel : https://t.me/psychdelicmushroomhempdispensary

Fullz Info Store

PHOTO/SCANS DL
Canada SCANS DL
United Kingdom SCANS DL
United States SCANS DL
Germany SCANS DL
Italy SCANS DL

- Fullz info USA

Fullz info USA+SSN
Fullz info USA+DL
Fullz info USA+AN:RN
Fullz info USA+Credit Score
Fullz info ID Scan Front+back+ssn+selfie
Fullz info Business

- Fullz info CA

Fullz info CA+SIN

- Fullz info UK

Tele Channel : https://t.me/psychdelicmushroomhempdispensary
ALL KIND OF FULLZ
UK FULLZ WITH NIN ..
UK FULLZ RANDOM ...
UK FULLZ WITH BANK ( BARCLAYS , HSBC , NATIONWIDE )
UK FULLZ WITH MOBILE NETWORK PROVIDERS (O2 , EE , VODAFONE..)
UK FULLZ DEAD + PHONE PROVIDER
UK FULLZ WITH AGE RANGE ..
UK FULLZ WITH SPECIFIC DOOR..
UK FULLZ WITH VBV
ALL OF THEM ARE FRESH FULLZ DEAD AND NOT RESOLD.
Tele Channel : https://t.me/psychdelicmushroomhempdispensary

---There are also many countries listed below---

Fullz info Argentina https://t.me/psychdelicmushroomhempdispensary
Fullz info Marokko https://t.me/psychdelicmushroomhempdispensary
Fullz info Russia https://t.me/psychdelicmushroomhempdispensary
Fullz info Romania https://t.me/psychdelicmushroomhempdispensary
Fullz info Czechia https://t.me/psychdelicmushroomhempdispensary
Fullz info Greece https://t.me/psychdelicmushroomhempdispensary
Fullz info Hungary https://t.me/psychdelicmushroomhempdispensary
Fullz info Latvia https://t.me/psychdelicmushroomhempdispensary
Fullz info Lithuania https://t.me/psychdelicmushroomhempdispensary
Fullz info Switzerland https://t.me/psychdelicmushroomhempdispensary
Fullz info Cyprus https://t.me/psychdelicmushroomhempdispensary
Fullz info Estonia https://t.me/psychdelicmushroomhempdispensary
Fullz info Netherlands https://t.me/psychdelicmushroomhempdispensary
Fullz info Belgium https://t.me/psychdelicmushroomhempdispensary
Fullz info Norway https://t.me/psychdelicmushroomhempdispensary
Fullz info Sweden https://t.me/psychdelicmushroomhempdispensary
Fullz info Ireland https://t.me/psychdelicmushroomhempdispensary
Fullz info Danmark https://t.me/psychdelicmushroomhempdispensary
Fullz info Spain 

[docker-dev] BUY LOWEST CREDIT CLONE CARD BALANCE

[Frank Domm]

Credit card cloning refers to making an unauthorized copy of a credit card. 
This practice is also sometimes called skimming. Thieves copy information 
at a credit card terminal using an electronic device and transfer the data 
from the stolen card to a new card or rewrite an existing card with the 
information.
https://t.me/psychdelicmushroomhempdispensary
https://t.me/psychdelicmushroomhempdispensary
https://t.me/psychdelicmushroomhempdispensary

• HOW CREDIT CARD CLONING WORKS 
>From the perspective of the thieves, cloning can be a very effective way to 
obtain credit card information, because it does not require the physical 
credit card to be stolen. Instead, they simply use an electronic device to 
covertly scan the card's information and copy it into the device’s memory. 
The thieves can then access that information digitally, or else download 
the information onto a separate credit card that is already in their 
possession.
https://t.me/psychdelicmushroomhempdispensary
https://t.me/psychdelicmushroomhempdispensary

•CAN A CLONED CARD BE USED AT AN ATM?
   This cloned data can then be transferred to another card, creating a 
duplicate. If the criminal also has the card's PIN (personal identification 
number), they can use the cloned card to withdraw money from the 
cardholder's account at an ATM.
https://t.me/psychdelicmushroomhempdispensary
https://t.me/psychdelicmushroomhempdispensary
https://t.me/psychdelicmushroomhempdispensary

• HOW TO USE THE CLONED CARD'S AT THE ATM MACHINE :
Step 1: Insert ATM Card.
Step 2: Select the Language.
Step 3: Enter 4 Digit ATM Pin.
Step 4: Select Your Transaction.
Step 5: Select Your Account.
Step 6: Enter the Withdrawal Money(withdraw £500 every after 2 hours)
Step 7: Collect the Cash.
Step 8: Take a Printed Receipt.
https://t.me/psychdelicmushroomhempdispensary
https://t.me/psychdelicmushroomhempdispensary

Once the information is recorded it can be transferred onto the magnetic 
strip of a new card or can be used to overwrite data on an already stolen 
credit card. For cards that use a personal identification number (PIN) 
number in addition to a magnetic strip, such as debit cards, the PIN would 
need to be observed and recorded. This is sometimes difficult to 
accomplish, adding additional protection against having your card 
compromised.

https://t.me/psychdelicmushroomhempdispensary
https://t.me/psychdelicmushroomhempdispensary
https://t.me/psychdelicmushroomhempdispensary
Search Frequently Asked Questions. Skimming or cloning cards is when the 
details of your card from the magnetic strip are put onto a blank card and 
then the card is used without your knowledge or permission.

Tele Channel : https://t.me/psychdelicmushroomhempdispensary
 Sell Fullz info ssn dob dl Fresh And Good - Sell DL Scan Front, Back + SSN 
number USA-Cvv usa-uk-au-eu-inter


HELLO CLIENT MINE

Tele Channel : https://t.me/psychdelicmushroomhempdispensary

Fullz Info Store

PHOTO/SCANS DL
Canada SCANS DL
United Kingdom SCANS DL
United States SCANS DL
Germany SCANS DL
Italy SCANS DL

- Fullz info USA

Fullz info USA+SSN
Fullz info USA+DL
Fullz info USA+AN:RN
Fullz info USA+Credit Score
Fullz info ID Scan Front+back+ssn+selfie
Fullz info Business

- Fullz info CA

Fullz info CA+SIN

- Fullz info UK

Tele Channel : https://t.me/psychdelicmushroomhempdispensary
ALL KIND OF FULLZ
UK FULLZ WITH NIN ..
UK FULLZ RANDOM ...
UK FULLZ WITH BANK ( BARCLAYS , HSBC , NATIONWIDE )
UK FULLZ WITH MOBILE NETWORK PROVIDERS (O2 , EE , VODAFONE..)
UK FULLZ DEAD + PHONE PROVIDER
UK FULLZ WITH AGE RANGE ..
UK FULLZ WITH SPECIFIC DOOR..
UK FULLZ WITH VBV
ALL OF THEM ARE FRESH FULLZ DEAD AND NOT RESOLD.
Tele Channel : https://t.me/psychdelicmushroomhempdispensary

---There are also many countries listed below---

Fullz info Argentina https://t.me/psychdelicmushroomhempdispensary
Fullz info Marokko https://t.me/psychdelicmushroomhempdispensary
Fullz info Russia https://t.me/psychdelicmushroomhempdispensary
Fullz info Romania https://t.me/psychdelicmushroomhempdispensary
Fullz info Czechia https://t.me/psychdelicmushroomhempdispensary
Fullz info Greece https://t.me/psychdelicmushroomhempdispensary
Fullz info Hungary https://t.me/psychdelicmushroomhempdispensary
Fullz info Latvia https://t.me/psychdelicmushroomhempdispensary
Fullz info Lithuania https://t.me/psychdelicmushroomhempdispensary
Fullz info Switzerland https://t.me/psychdelicmushroomhempdispensary
Fullz info Cyprus https://t.me/psychdelicmushroomhempdispensary
Fullz info Estonia https://t.me/psychdelicmushroomhempdispensary
Fullz info Netherlands https://t.me/psychdelicmushroomhempdispensary
Fullz info Belgium https://t.me/psychdelicmushroomhempdispensary
Fullz info Norway https://t.me/psychdelicmushroomhempdispensary
Fullz info Sweden https://t.me/psychdelicmushroomhempdispensary
Fullz info Ireland https://t.me/psychdelicmushroomhempdispensary
Fullz info Danmark https://t.me/psychdelicmushroomhempdispensary
Fullz info Spain 

[Bug 2065579] Re: [UBUNTU 22.04] OS guest boot issues on 9p filesystem

[Frank Heimes]

Please let me jump in (for TZ reasons).

The patch "debian/patches/ubuntu/lp-2065579-9pfs-allow-sockets.patch"
(as always referenced in debin/changelog) that Sergio created and that
is incl. in the PPA build is this:

From: Sergio Durigan Junior 
Date: Thu, 30 May 2024 16:45:56 -0400
Subject: hw/9pfs/9p-util.h: Also allow sockets to be opened

Forwarded: not-needed
Bug-Ubuntu: https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/2065579
---
 hw/9pfs/9p-util.h | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/hw/9pfs/9p-util.h b/hw/9pfs/9p-util.h
index ff32179..a3df012 100644
--- a/hw/9pfs/9p-util.h
+++ b/hw/9pfs/9p-util.h
@@ -47,7 +47,8 @@ static inline int close_if_special_file(int fd)
 close_preserve_errno(fd);
 return -1;
 }
-if (!S_ISREG(stbuf.st_mode) && !S_ISDIR(stbuf.st_mode)) {
+if (!S_ISREG(stbuf.st_mode) && !S_ISDIR(stbuf.st_mode)
+&& !S_ISSOCK(stbuf.st_mode)) {
 error_report_once(
 "9p: broken or compromised client detected; attempt to open "
 "special file (i.e. neither regular file, nor directory)"

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2065579

Title:
  [UBUNTU 22.04] OS guest boot issues on 9p filesystem

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/2065579/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[docker-dev] Buy reliable credit clone card

[Frank Domm]

Credit card cloning refers to making an unauthorized copy of a credit card. 
This practice is also sometimes called skimming. Thieves copy information 
at a credit card terminal using an electronic device and transfer the data 
from the stolen card to a new card or rewrite an existing card with the 
information.
https://t.me/psychdelicmushroomhempdispensary
https://t.me/psychdelicmushroomhempdispensary
https://t.me/psychdelicmushroomhempdispensary

• HOW CREDIT CARD CLONING WORKS 
>From the perspective of the thieves, cloning can be a very effective way to 
obtain credit card information, because it does not require the physical 
credit card to be stolen. Instead, they simply use an electronic device to 
covertly scan the card's information and copy it into the device’s memory. 
The thieves can then access that information digitally, or else download 
the information onto a separate credit card that is already in their 
possession.
https://t.me/psychdelicmushroomhempdispensary
https://t.me/psychdelicmushroomhempdispensary

•CAN A CLONED CARD BE USED AT AN ATM?
   This cloned data can then be transferred to another card, creating a 
duplicate. If the criminal also has the card's PIN (personal identification 
number), they can use the cloned card to withdraw money from the 
cardholder's account at an ATM.
https://t.me/psychdelicmushroomhempdispensary
https://t.me/psychdelicmushroomhempdispensary
https://t.me/psychdelicmushroomhempdispensary

• HOW TO USE THE CLONED CARD'S AT THE ATM MACHINE :
Step 1: Insert ATM Card.
Step 2: Select the Language.
Step 3: Enter 4 Digit ATM Pin.
Step 4: Select Your Transaction.
Step 5: Select Your Account.
Step 6: Enter the Withdrawal Money(withdraw £500 every after 2 hours)
Step 7: Collect the Cash.
Step 8: Take a Printed Receipt.
https://t.me/psychdelicmushroomhempdispensary
https://t.me/psychdelicmushroomhempdispensary

Once the information is recorded it can be transferred onto the magnetic 
strip of a new card or can be used to overwrite data on an already stolen 
credit card. For cards that use a personal identification number (PIN) 
number in addition to a magnetic strip, such as debit cards, the PIN would 
need to be observed and recorded. This is sometimes difficult to 
accomplish, adding additional protection against having your card 
compromised.

https://t.me/psychdelicmushroomhempdispensary
https://t.me/psychdelicmushroomhempdispensary
https://t.me/psychdelicmushroomhempdispensary
Search Frequently Asked Questions. Skimming or cloning cards is when the 
details of your card from the magnetic strip are put onto a blank card and 
then the card is used without your knowledge or permission.

Tele Channel : https://t.me/psychdelicmushroomhempdispensary
 Sell Fullz info ssn dob dl Fresh And Good - Sell DL Scan Front, Back + SSN 
number USA-Cvv usa-uk-au-eu-inter


HELLO CLIENT MINE

Tele Channel : https://t.me/psychdelicmushroomhempdispensary

Fullz Info Store

PHOTO/SCANS DL
Canada SCANS DL
United Kingdom SCANS DL
United States SCANS DL
Germany SCANS DL
Italy SCANS DL

- Fullz info USA

Fullz info USA+SSN
Fullz info USA+DL
Fullz info USA+AN:RN
Fullz info USA+Credit Score
Fullz info ID Scan Front+back+ssn+selfie
Fullz info Business

- Fullz info CA

Fullz info CA+SIN

- Fullz info UK

Tele Channel : https://t.me/psychdelicmushroomhempdispensary
ALL KIND OF FULLZ
UK FULLZ WITH NIN ..
UK FULLZ RANDOM ...
UK FULLZ WITH BANK ( BARCLAYS , HSBC , NATIONWIDE )
UK FULLZ WITH MOBILE NETWORK PROVIDERS (O2 , EE , VODAFONE..)
UK FULLZ DEAD + PHONE PROVIDER
UK FULLZ WITH AGE RANGE ..
UK FULLZ WITH SPECIFIC DOOR..
UK FULLZ WITH VBV
ALL OF THEM ARE FRESH FULLZ DEAD AND NOT RESOLD.
Tele Channel : https://t.me/psychdelicmushroomhempdispensary

---There are also many countries listed below---

Fullz info Argentina https://t.me/psychdelicmushroomhempdispensary
Fullz info Marokko https://t.me/psychdelicmushroomhempdispensary
Fullz info Russia https://t.me/psychdelicmushroomhempdispensary
Fullz info Romania https://t.me/psychdelicmushroomhempdispensary
Fullz info Czechia https://t.me/psychdelicmushroomhempdispensary
Fullz info Greece https://t.me/psychdelicmushroomhempdispensary
Fullz info Hungary https://t.me/psychdelicmushroomhempdispensary
Fullz info Latvia https://t.me/psychdelicmushroomhempdispensary
Fullz info Lithuania https://t.me/psychdelicmushroomhempdispensary
Fullz info Switzerland https://t.me/psychdelicmushroomhempdispensary
Fullz info Cyprus https://t.me/psychdelicmushroomhempdispensary
Fullz info Estonia https://t.me/psychdelicmushroomhempdispensary
Fullz info Netherlands https://t.me/psychdelicmushroomhempdispensary
Fullz info Belgium https://t.me/psychdelicmushroomhempdispensary
Fullz info Norway https://t.me/psychdelicmushroomhempdispensary
Fullz info Sweden https://t.me/psychdelicmushroomhempdispensary
Fullz info Ireland https://t.me/psychdelicmushroomhempdispensary
Fullz info Danmark https://t.me/psychdelicmushroomhempdispensary
Fullz info Spain 

Re: [tor-relays] Tor relays Bazinga and JPsi2 to be shut down

[Frank Lý via tor-relays]

Thank you for your contribution to the Tor network. If you are still interested 
in migrating the reputation of these two relays to another hosting provider 
such as Contabo, you can back up their Tor identity keys. The default directory 
for these on Linux are within `/var/lib/tor/keys`.

Frank

May 29, 2024, 9:38 AM by tor-relays@lists.torproject.org:

> Hi all,
>
> I have been operating the relays
> - Bazinga B198C0B4B8C551F174FBB841A172616E3DB3124D
> - JPsi2   F6EC46933CE8D4FAD5CCDAA8B1C5A377685FC521
> for about 10 years.
>
> The hosting provider stops providing their current service and their 
> successor services are not Tor-friendly anymore.
> Hence, these relays will be shut down by June 2 2024.
>
> My third relay
> - SafeAndEffective A508096AA0C899F4E6ECD1D9C35037B89008BCBA
> is unaffected.
> ___
> tor-relays mailing list
> tor-relays@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
>

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Directory authorities not giving weight to a relay

[Frank Lý via tor-relays]

> The server has capacity and is dedicated solely to being a relay, and the ISP 
> is in the good providers list.

MDCLOUD LTD (AS203394) does not exist on the Good Bad ISPs list. In addition, 
the contact information provided in the `torrc` does not match the email 
address you used to participate in the `tor-relays` mailing list.

Frank

May 30, 2024, 11:23 PM by tor-relays@lists.torproject.org:

> Greetings everyone!
>
> Almost three months ago I have set up my first node. Everything seemed to be 
> going great at first and as documented in the tor lifecycle blog post.
> A few days after being set up the weight drastically dropped to around 
> twenty. This seemed a bit odd since that same blog post doesn't mention 
> anything about weight dropping so much, but it does about bandwidth, ao I 
> just shrugged it off and assumed it was normal.
>
> Anyway, fast forward to today, and the weight hasn't really gotten above two 
> hundred, it has been a month and a half I think since the weight drop, and it 
> has been stale at a weight of between one hundred eighty and two hundred.
>
> I can't put my finger on what is exactly the problem, the relay currently has 
> six flags: Fast, HSDir, Running, Stable, V2Dir and Valid. Shortly after the 
> drop I have even seen the Guard flag for like a day.
> The server has capacity and is dedicated solely to being a relay, and the ISP 
> is in the good providers list.
>
> The fingerprint of the node is ACC72E6D0FA76168AE1BA7F26996D191FEA7C9D8. 
> Maybe someone in this list can give me a hand and point me in the right 
> direction.
>
> Thank you in advance!
>

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[PATCH 1/6] target/riscv: Introduce extension implied rules definition

[frank . chang]

From: Frank Chang 

RISCVCPUImpliedExtsRule is created to store the implied rules.
'is_misa' flag is used to distinguish whether the rule is derived
from the MISA or other extensions.
'ext' stores the MISA bit if 'is_misa' is true. Otherwise, it stores
the offset of the extension defined in RISCVCPUConfig. 'ext' will also
serve as the key of the hash tables to look up the rule in the following
commit.

Signed-off-by: Frank Chang 
Reviewed-by: Jerry Zhang Jian 
---
 target/riscv/cpu.c |  8 
 target/riscv/cpu.h | 17 +
 2 files changed, 25 insertions(+)

diff --git a/target/riscv/cpu.c b/target/riscv/cpu.c
index cee6fc4a9a..c7e5cec7ef 100644
--- a/target/riscv/cpu.c
+++ b/target/riscv/cpu.c
@@ -2242,6 +2242,14 @@ RISCVCPUProfile *riscv_profiles[] = {
 NULL,
 };

+RISCVCPUImpliedExtsRule *riscv_misa_implied_rules[] = {
+NULL
+};
+
+RISCVCPUImpliedExtsRule *riscv_ext_implied_rules[] = {
+NULL
+};
+
 static Property riscv_cpu_properties[] = {
 DEFINE_PROP_BOOL("debug", RISCVCPU, cfg.debug, true),

diff --git a/target/riscv/cpu.h b/target/riscv/cpu.h
index 1501868008..b8ebff6631 100644
--- a/target/riscv/cpu.h
+++ b/target/riscv/cpu.h
@@ -122,6 +122,23 @@ typedef enum {
 EXT_STATUS_DIRTY,
 } RISCVExtStatus;

+typedef struct riscv_cpu_implied_exts_rule RISCVCPUImpliedExtsRule;
+
+struct riscv_cpu_implied_exts_rule {
+bool enabled;
+/* True if this is a MISA implied rule. */
+bool is_misa;
+/* ext is MISA bit if is_misa flag is true, else extension offset. */
+const uint32_t ext;
+const uint32_t implied_misas;
+const uint32_t implied_exts[];
+};
+
+extern RISCVCPUImpliedExtsRule *riscv_misa_implied_rules[];
+extern RISCVCPUImpliedExtsRule *riscv_ext_implied_rules[];
+
+#define RISCV_IMPLIED_EXTS_RULE_END -1
+
 #define MMU_USER_IDX 3

 #define MAX_RISCV_PMPS (16)
--
2.43.2

[PATCH 5/6] target/riscv: Add Zc extension implied rule

[frank . chang]

From: Frank Chang 

Zc extension has special implied rules that need to be handled separately.

Signed-off-by: Frank Chang 
Reviewed-by: Jerry Zhang Jian 
---
 target/riscv/tcg/tcg-cpu.c | 34 ++
 1 file changed, 34 insertions(+)

diff --git a/target/riscv/tcg/tcg-cpu.c b/target/riscv/tcg/tcg-cpu.c
index 243a8547a2..c78da393bc 100644
--- a/target/riscv/tcg/tcg-cpu.c
+++ b/target/riscv/tcg/tcg-cpu.c
@@ -892,11 +892,45 @@ static void cpu_enable_implied_rule(RISCVCPU *cpu,
 }
 }

+/* Zc extension has special implied rules that need to be handled separately. 
*/
+static void cpu_enable_zc_implied_rules(RISCVCPU *cpu)
+{
+RISCVCPUClass *mcc = RISCV_CPU_GET_CLASS(cpu);
+CPURISCVState *env = >env;
+
+if (cpu->cfg.ext_zce) {
+cpu_cfg_ext_auto_update(cpu, CPU_CFG_OFFSET(ext_zca), true);
+cpu_cfg_ext_auto_update(cpu, CPU_CFG_OFFSET(ext_zcb), true);
+cpu_cfg_ext_auto_update(cpu, CPU_CFG_OFFSET(ext_zcmp), true);
+cpu_cfg_ext_auto_update(cpu, CPU_CFG_OFFSET(ext_zcmt), true);
+
+if (riscv_has_ext(env, RVF) && mcc->misa_mxl_max == MXL_RV32) {
+cpu_cfg_ext_auto_update(cpu, CPU_CFG_OFFSET(ext_zcf), true);
+}
+}
+
+/* Zca, Zcd and Zcf has a PRIV 1.12.0 restriction */
+if (riscv_has_ext(env, RVC) && env->priv_ver >= PRIV_VERSION_1_12_0) {
+cpu_cfg_ext_auto_update(cpu, CPU_CFG_OFFSET(ext_zca), true);
+
+if (riscv_has_ext(env, RVF) && mcc->misa_mxl_max == MXL_RV32) {
+cpu_cfg_ext_auto_update(cpu, CPU_CFG_OFFSET(ext_zcf), true);
+}
+
+if (riscv_has_ext(env, RVD)) {
+cpu_cfg_ext_auto_update(cpu, CPU_CFG_OFFSET(ext_zcd), true);
+}
+}
+}
+
 static void riscv_cpu_enable_implied_rules(RISCVCPU *cpu)
 {
 RISCVCPUImpliedExtsRule *rule;
 int i;

+/* Enable the implied extensions for Zc. */
+cpu_enable_zc_implied_rules(cpu);
+
 /* Enable the implied MISAs. */
 for (i = 0; (rule = riscv_misa_implied_rules[i]); i++) {
 if (riscv_has_ext(>env, rule->ext)) {
--
2.43.2

[PATCH 0/6] Introduce extension implied rules

[frank . chang]

From: Frank Chang 

Currently, the implied extensions are enabled and checked in
riscv_cpu_validate_set_extensions(). However, the order of enabling the
implied extensions must follow a strict sequence, which is error-prone.

This patchset introduce extension implied rule helpers to enable the
implied extensions. This also eliminates the old-fashioned ordering
requirement. For example, Zvksg implies Zvks, Zvks implies Zvksed, etc.,
removing the need to check the implied rules of Zvksg before Zvks.

The idea [1] and the implied rules [2] are referenced from LLVM.

[1] 
https://github.com/llvm/llvm-project/blob/main/llvm/lib/TargetParser/RISCVISAInfo.cpp#L875
[2] 
https://github.com/llvm/llvm-project/blob/main/llvm/lib/Target/RISCV/RISCVFeatures.td

Frank Chang (6):
  target/riscv: Introduce extension implied rules definition
  target/riscv: Introduce extension implied rule helpers
  target/riscv: Add MISA implied rules
  target/riscv: Add standard extension implied rules
  target/riscv: Add Zc extension implied rule
  target/riscv: Remove extension auto-update check statements

 target/riscv/cpu.c | 396 +
 target/riscv/cpu.h |  17 ++
 target/riscv/tcg/tcg-cpu.c | 233 +++---
 3 files changed, 531 insertions(+), 115 deletions(-)

--
2.43.2

[PATCH 3/6] target/riscv: Add MISA implied rules

[frank . chang]

From: Frank Chang 

Add MISA extension implied rules to enable the implied extensions
of MISA recursively.

Signed-off-by: Frank Chang 
Reviewed-by: Jerry Zhang Jian 
---
 target/riscv/cpu.c | 50 +-
 1 file changed, 49 insertions(+), 1 deletion(-)

diff --git a/target/riscv/cpu.c b/target/riscv/cpu.c
index c7e5cec7ef..a6e9055c5f 100644
--- a/target/riscv/cpu.c
+++ b/target/riscv/cpu.c
@@ -2242,8 +2242,56 @@ RISCVCPUProfile *riscv_profiles[] = {
 NULL,
 };

+static RISCVCPUImpliedExtsRule RVA_IMPLIED = {
+.is_misa = true,
+.ext = RVA,
+.implied_exts = {
+CPU_CFG_OFFSET(ext_zalrsc), CPU_CFG_OFFSET(ext_zaamo),
+
+RISCV_IMPLIED_EXTS_RULE_END
+},
+};
+
+static RISCVCPUImpliedExtsRule RVD_IMPLIED = {
+.is_misa = true,
+.ext = RVD,
+.implied_misas = RVF,
+.implied_exts = { RISCV_IMPLIED_EXTS_RULE_END },
+};
+
+static RISCVCPUImpliedExtsRule RVF_IMPLIED = {
+.is_misa = true,
+.ext = RVF,
+.implied_exts = {
+CPU_CFG_OFFSET(ext_zicsr),
+
+RISCV_IMPLIED_EXTS_RULE_END
+},
+};
+
+static RISCVCPUImpliedExtsRule RVM_IMPLIED = {
+.is_misa = true,
+.ext = RVM,
+.implied_exts = {
+CPU_CFG_OFFSET(ext_zmmul),
+
+RISCV_IMPLIED_EXTS_RULE_END
+},
+};
+
+static RISCVCPUImpliedExtsRule RVV_IMPLIED = {
+.is_misa = true,
+.ext = RVV,
+.implied_exts = {
+CPU_CFG_OFFSET(ext_zve64d),
+
+RISCV_IMPLIED_EXTS_RULE_END
+},
+};
+
 RISCVCPUImpliedExtsRule *riscv_misa_implied_rules[] = {
-NULL
+_IMPLIED, _IMPLIED, _IMPLIED,
+_IMPLIED, _IMPLIED, NULL
 };

 RISCVCPUImpliedExtsRule *riscv_ext_implied_rules[] = {
--
2.43.2

[PATCH 4/6] target/riscv: Add standard extension implied rules

[frank . chang]

From: Frank Chang 

Add standard extension implied rules to enable the implied extensions of
the standard extension recursively.

Signed-off-by: Frank Chang 
Reviewed-by: Jerry Zhang Jian 
---
 target/riscv/cpu.c | 340 +
 1 file changed, 340 insertions(+)

diff --git a/target/riscv/cpu.c b/target/riscv/cpu.c
index a6e9055c5f..80b238060a 100644
--- a/target/riscv/cpu.c
+++ b/target/riscv/cpu.c
@@ -2289,12 +2289,352 @@ static RISCVCPUImpliedExtsRule RVV_IMPLIED = {
 },
 };

+static RISCVCPUImpliedExtsRule ZCB_IMPLIED = {
+.ext = CPU_CFG_OFFSET(ext_zcb),
+.implied_exts = {
+CPU_CFG_OFFSET(ext_zca),
+
+RISCV_IMPLIED_EXTS_RULE_END
+},
+};
+
+static RISCVCPUImpliedExtsRule ZCD_IMPLIED = {
+.ext = CPU_CFG_OFFSET(ext_zcd),
+.implied_misas = RVD,
+.implied_exts = {
+CPU_CFG_OFFSET(ext_zca),
+
+RISCV_IMPLIED_EXTS_RULE_END
+},
+};
+
+static RISCVCPUImpliedExtsRule ZCE_IMPLIED = {
+.ext = CPU_CFG_OFFSET(ext_zce),
+.implied_exts = {
+CPU_CFG_OFFSET(ext_zcb), CPU_CFG_OFFSET(ext_zcmp),
+CPU_CFG_OFFSET(ext_zcmt),
+
+RISCV_IMPLIED_EXTS_RULE_END
+},
+};
+
+static RISCVCPUImpliedExtsRule ZCF_IMPLIED = {
+.ext = CPU_CFG_OFFSET(ext_zcf),
+.implied_misas = RVF,
+.implied_exts = {
+CPU_CFG_OFFSET(ext_zca),
+
+RISCV_IMPLIED_EXTS_RULE_END
+},
+};
+
+static RISCVCPUImpliedExtsRule ZCMP_IMPLIED = {
+.ext = CPU_CFG_OFFSET(ext_zcmp),
+.implied_exts = {
+CPU_CFG_OFFSET(ext_zca),
+
+RISCV_IMPLIED_EXTS_RULE_END
+},
+};
+
+static RISCVCPUImpliedExtsRule ZCMT_IMPLIED = {
+.ext = CPU_CFG_OFFSET(ext_zcmt),
+.implied_exts = {
+CPU_CFG_OFFSET(ext_zca), CPU_CFG_OFFSET(ext_zicsr),
+
+RISCV_IMPLIED_EXTS_RULE_END
+},
+};
+
+static RISCVCPUImpliedExtsRule ZDINX_IMPLIED = {
+.ext = CPU_CFG_OFFSET(ext_zdinx),
+.implied_exts = {
+CPU_CFG_OFFSET(ext_zfinx),
+
+RISCV_IMPLIED_EXTS_RULE_END
+},
+};
+
+static RISCVCPUImpliedExtsRule ZFA_IMPLIED = {
+.ext = CPU_CFG_OFFSET(ext_zfa),
+.implied_misas = RVF,
+.implied_exts = { RISCV_IMPLIED_EXTS_RULE_END },
+};
+
+static RISCVCPUImpliedExtsRule ZFBFMIN_IMPLIED = {
+.ext = CPU_CFG_OFFSET(ext_zfbfmin),
+.implied_misas = RVF,
+.implied_exts = { RISCV_IMPLIED_EXTS_RULE_END },
+};
+
+static RISCVCPUImpliedExtsRule ZFH_IMPLIED = {
+.ext = CPU_CFG_OFFSET(ext_zfh),
+.implied_exts = {
+CPU_CFG_OFFSET(ext_zfhmin),
+
+RISCV_IMPLIED_EXTS_RULE_END
+},
+};
+
+static RISCVCPUImpliedExtsRule ZFHMIN_IMPLIED = {
+.ext = CPU_CFG_OFFSET(ext_zfhmin),
+.implied_misas = RVF,
+.implied_exts = { RISCV_IMPLIED_EXTS_RULE_END },
+};
+
+static RISCVCPUImpliedExtsRule ZFINX_IMPLIED = {
+.ext = CPU_CFG_OFFSET(ext_zfinx),
+.implied_exts = {
+CPU_CFG_OFFSET(ext_zicsr),
+
+RISCV_IMPLIED_EXTS_RULE_END
+},
+};
+
+static RISCVCPUImpliedExtsRule ZHINX_IMPLIED = {
+.ext = CPU_CFG_OFFSET(ext_zhinx),
+.implied_exts = {
+CPU_CFG_OFFSET(ext_zhinxmin),
+
+RISCV_IMPLIED_EXTS_RULE_END
+},
+};
+
+static RISCVCPUImpliedExtsRule ZHINXMIN_IMPLIED = {
+.ext = CPU_CFG_OFFSET(ext_zhinxmin),
+.implied_exts = {
+CPU_CFG_OFFSET(ext_zfinx),
+
+RISCV_IMPLIED_EXTS_RULE_END
+},
+};
+
+static RISCVCPUImpliedExtsRule ZICNTR_IMPLIED = {
+.ext = CPU_CFG_OFFSET(ext_zicntr),
+.implied_exts = {
+CPU_CFG_OFFSET(ext_zicsr),
+
+RISCV_IMPLIED_EXTS_RULE_END
+},
+};
+
+static RISCVCPUImpliedExtsRule ZIHPM_IMPLIED = {
+.ext = CPU_CFG_OFFSET(ext_zihpm),
+.implied_exts = {
+CPU_CFG_OFFSET(ext_zicsr),
+
+RISCV_IMPLIED_EXTS_RULE_END
+},
+};
+
+static RISCVCPUImpliedExtsRule ZK_IMPLIED = {
+.ext = CPU_CFG_OFFSET(ext_zk),
+.implied_exts = {
+CPU_CFG_OFFSET(ext_zkn), CPU_CFG_OFFSET(ext_zkr),
+CPU_CFG_OFFSET(ext_zkt),
+
+RISCV_IMPLIED_EXTS_RULE_END
+},
+};
+
+static RISCVCPUImpliedExtsRule ZKN_IMPLIED = {
+.ext = CPU_CFG_OFFSET(ext_zkn),
+.implied_exts = {
+CPU_CFG_OFFSET(ext_zbkb), CPU_CFG_OFFSET(ext_zbkc),
+CPU_CFG_OFFSET(ext_zbkx), CPU_CFG_OFFSET(ext_zkne),
+CPU_CFG_OFFSET(ext_zknd), CPU_CFG_OFFSET(ext_zknh),
+
+RISCV_IMPLIED_EXTS_RULE_END
+},
+};
+
+static RISCVCPUImpliedExtsRule ZKS_IMPLIED = {
+.ext = CPU_CFG_OFFSET(ext_zks),
+.implied_exts = {
+CPU_CFG_OFFSET(ext_zbkb), CPU_CFG_OFFSET(ext_zbkc),
+CPU_CFG_OFFSET(ext_zbkx), CPU_CFG_OFFSET(ext_zksed),
+CPU_CFG_OFFSET(ext_zksh),
+
+RISCV_IMPLIED_EXTS_RULE_END
+},
+};
+
+static RISCVCPUImpliedExtsRule ZVBB_IMPLIED = {
+.ext = CPU_CFG_OFFSET(ext_zvbb),
+.implied_exts = {
+CPU_CFG_OFFSET(ext_zvkb),
+
+RISCV_IMPLIED_EXTS_RULE_END
+},
+};
+
+static RISCVCPUImpliedExtsRule ZVE32F_IMPLIED = {
+.ext = CPU_CFG_OFFSET(ext_zve32f

[PATCH 2/6] target/riscv: Introduce extension implied rule helpers

[frank . chang]

From: Frank Chang 

Introduce helpers to enable the extensions based on the implied rules.
The implied extensions are enabled recursively, so we don't have to
expand all of them manually. This also eliminates the old-fashioned
ordering requirement. For example, Zvksg implies Zvks, Zvks implies
Zvksed, etc., removing the need to check the implied rules of Zvksg
before Zvks.

Signed-off-by: Frank Chang 
Reviewed-by: Jerry Zhang Jian 
---
 target/riscv/tcg/tcg-cpu.c | 84 ++
 1 file changed, 84 insertions(+)

diff --git a/target/riscv/tcg/tcg-cpu.c b/target/riscv/tcg/tcg-cpu.c
index 683f604d9f..243a8547a2 100644
--- a/target/riscv/tcg/tcg-cpu.c
+++ b/target/riscv/tcg/tcg-cpu.c
@@ -36,6 +36,9 @@
 static GHashTable *multi_ext_user_opts;
 static GHashTable *misa_ext_user_opts;

+static GHashTable *misa_implied_rules;
+static GHashTable *ext_implied_rules;
+
 static bool cpu_cfg_ext_is_user_set(uint32_t ext_offset)
 {
 return g_hash_table_contains(multi_ext_user_opts,
@@ -833,11 +836,90 @@ static void riscv_cpu_validate_profiles(RISCVCPU *cpu)
 }
 }

+static void riscv_cpu_init_implied_exts_rules(void)
+{
+RISCVCPUImpliedExtsRule *rule;
+int i;
+
+for (i = 0; (rule = riscv_misa_implied_rules[i]); i++) {
+g_hash_table_insert(misa_implied_rules, GUINT_TO_POINTER(rule->ext),
+(gpointer)rule);
+}
+
+for (i = 0; (rule = riscv_ext_implied_rules[i]); i++) {
+g_hash_table_insert(ext_implied_rules, GUINT_TO_POINTER(rule->ext),
+(gpointer)rule);
+}
+}
+
+static void cpu_enable_implied_rule(RISCVCPU *cpu,
+RISCVCPUImpliedExtsRule *rule)
+{
+CPURISCVState *env = >env;
+RISCVCPUImpliedExtsRule *ir;
+int i;
+
+if (!rule->enabled) {
+/* Enable the implied MISAs. */
+if (rule->implied_misas) {
+riscv_cpu_set_misa_ext(env, env->misa_ext | rule->implied_misas);
+
+for (i = 0; misa_bits[i] != 0; i++) {
+if (rule->implied_misas & misa_bits[i]) {
+ir = g_hash_table_lookup(misa_implied_rules,
+ GUINT_TO_POINTER(misa_bits[i]));
+
+if (ir) {
+cpu_enable_implied_rule(cpu, ir);
+}
+}
+}
+}
+
+/* Enable the implied extensions. */
+for (i = 0; rule->implied_exts[i] != RISCV_IMPLIED_EXTS_RULE_END; i++) 
{
+cpu_cfg_ext_auto_update(cpu, rule->implied_exts[i], true);
+
+ir = g_hash_table_lookup(ext_implied_rules,
+ GUINT_TO_POINTER(rule->implied_exts[i]));
+
+if (ir) {
+cpu_enable_implied_rule(cpu, ir);
+}
+}
+
+rule->enabled = true;
+}
+}
+
+static void riscv_cpu_enable_implied_rules(RISCVCPU *cpu)
+{
+RISCVCPUImpliedExtsRule *rule;
+int i;
+
+/* Enable the implied MISAs. */
+for (i = 0; (rule = riscv_misa_implied_rules[i]); i++) {
+if (riscv_has_ext(>env, rule->ext)) {
+cpu_enable_implied_rule(cpu, rule);
+}
+}
+
+/* Enable the implied extensions. */
+for (i = 0; (rule = riscv_ext_implied_rules[i]); i++) {
+if (isa_ext_is_enabled(cpu, rule->ext)) {
+cpu_enable_implied_rule(cpu, rule);
+}
+}
+}
+
 void riscv_tcg_cpu_finalize_features(RISCVCPU *cpu, Error **errp)
 {
 CPURISCVState *env = >env;
 Error *local_err = NULL;

+riscv_cpu_init_implied_exts_rules();
+riscv_cpu_enable_implied_rules(cpu);
+
 riscv_cpu_validate_misa_priv(env, _err);
 if (local_err != NULL) {
 error_propagate(errp, local_err);
@@ -1343,6 +1425,8 @@ static void riscv_tcg_cpu_instance_init(CPUState *cs)

 misa_ext_user_opts = g_hash_table_new(NULL, g_direct_equal);
 multi_ext_user_opts = g_hash_table_new(NULL, g_direct_equal);
+misa_implied_rules = g_hash_table_new(NULL, g_direct_equal);
+ext_implied_rules = g_hash_table_new(NULL, g_direct_equal);
 riscv_cpu_add_user_properties(obj);

 if (riscv_cpu_has_max_extensions(obj)) {
--
2.43.2

[PATCH 6/6] target/riscv: Remove extension auto-update check statements

[frank . chang]

From: Frank Chang 

Remove the old-fashioned extension auto-update check statements as
they are replaced by the extension implied rules.

Signed-off-by: Frank Chang 
Reviewed-by: Jerry Zhang Jian 
---
 target/riscv/tcg/tcg-cpu.c | 115 -
 1 file changed, 115 deletions(-)

diff --git a/target/riscv/tcg/tcg-cpu.c b/target/riscv/tcg/tcg-cpu.c
index c78da393bc..570dff16cb 100644
--- a/target/riscv/tcg/tcg-cpu.c
+++ b/target/riscv/tcg/tcg-cpu.c
@@ -469,10 +469,6 @@ void riscv_cpu_validate_set_extensions(RISCVCPU *cpu, 
Error **errp)
 return;
 }

-if (cpu->cfg.ext_zfh) {
-cpu_cfg_ext_auto_update(cpu, CPU_CFG_OFFSET(ext_zfhmin), true);
-}
-
 if (cpu->cfg.ext_zfhmin && !riscv_has_ext(env, RVF)) {
 error_setg(errp, "Zfh/Zfhmin extensions require F extension");
 return;
@@ -494,9 +490,6 @@ void riscv_cpu_validate_set_extensions(RISCVCPU *cpu, Error 
**errp)
 error_propagate(errp, local_err);
 return;
 }
-
-/* The V vector extension depends on the Zve64d extension */
-cpu_cfg_ext_auto_update(cpu, CPU_CFG_OFFSET(ext_zve64d), true);
 }

 /* The Zve64d extension depends on the Zve64f extension */
@@ -505,18 +498,6 @@ void riscv_cpu_validate_set_extensions(RISCVCPU *cpu, 
Error **errp)
 error_setg(errp, "Zve64d/V extensions require D extension");
 return;
 }
-cpu_cfg_ext_auto_update(cpu, CPU_CFG_OFFSET(ext_zve64f), true);
-}
-
-/* The Zve64f extension depends on the Zve64x and Zve32f extensions */
-if (cpu->cfg.ext_zve64f) {
-cpu_cfg_ext_auto_update(cpu, CPU_CFG_OFFSET(ext_zve64x), true);
-cpu_cfg_ext_auto_update(cpu, CPU_CFG_OFFSET(ext_zve32f), true);
-}
-
-/* The Zve64x extension depends on the Zve32x extension */
-if (cpu->cfg.ext_zve64x) {
-cpu_cfg_ext_auto_update(cpu, CPU_CFG_OFFSET(ext_zve32x), true);
 }

 /* The Zve32f extension depends on the Zve32x extension */
@@ -525,11 +506,6 @@ void riscv_cpu_validate_set_extensions(RISCVCPU *cpu, 
Error **errp)
 error_setg(errp, "Zve32f/Zve64f extensions require F extension");
 return;
 }
-cpu_cfg_ext_auto_update(cpu, CPU_CFG_OFFSET(ext_zve32x), true);
-}
-
-if (cpu->cfg.ext_zvfh) {
-cpu_cfg_ext_auto_update(cpu, CPU_CFG_OFFSET(ext_zvfhmin), true);
 }

 if (cpu->cfg.ext_zvfhmin && !cpu->cfg.ext_zve32f) {
@@ -552,11 +528,6 @@ void riscv_cpu_validate_set_extensions(RISCVCPU *cpu, 
Error **errp)
 return;
 }

-/* Set the ISA extensions, checks should have happened above */
-if (cpu->cfg.ext_zhinx) {
-cpu_cfg_ext_auto_update(cpu, CPU_CFG_OFFSET(ext_zca), true);
-}
-
 if ((cpu->cfg.ext_zdinx || cpu->cfg.ext_zhinxmin) && !cpu->cfg.ext_zfinx) {
 error_setg(errp, "Zdinx/Zhinx/Zhinxmin extensions require Zfinx");
 return;
@@ -574,27 +545,6 @@ void riscv_cpu_validate_set_extensions(RISCVCPU *cpu, 
Error **errp)
 }
 }

-if (cpu->cfg.ext_zce) {
-cpu_cfg_ext_auto_update(cpu, CPU_CFG_OFFSET(ext_zca), true);
-cpu_cfg_ext_auto_update(cpu, CPU_CFG_OFFSET(ext_zcb), true);
-cpu_cfg_ext_auto_update(cpu, CPU_CFG_OFFSET(ext_zcmp), true);
-cpu_cfg_ext_auto_update(cpu, CPU_CFG_OFFSET(ext_zcmt), true);
-if (riscv_has_ext(env, RVF) && mcc->misa_mxl_max == MXL_RV32) {
-cpu_cfg_ext_auto_update(cpu, CPU_CFG_OFFSET(ext_zcf), true);
-}
-}
-
-/* zca, zcd and zcf has a PRIV 1.12.0 restriction */
-if (riscv_has_ext(env, RVC) && env->priv_ver >= PRIV_VERSION_1_12_0) {
-cpu_cfg_ext_auto_update(cpu, CPU_CFG_OFFSET(ext_zca), true);
-if (riscv_has_ext(env, RVF) && mcc->misa_mxl_max == MXL_RV32) {
-cpu_cfg_ext_auto_update(cpu, CPU_CFG_OFFSET(ext_zcf), true);
-}
-if (riscv_has_ext(env, RVD)) {
-cpu_cfg_ext_auto_update(cpu, CPU_CFG_OFFSET(ext_zcd), true);
-}
-}
-
 if (mcc->misa_mxl_max != MXL_RV32 && cpu->cfg.ext_zcf) {
 error_setg(errp, "Zcf extension is only relevant to RV32");
 return;
@@ -628,48 +578,6 @@ void riscv_cpu_validate_set_extensions(RISCVCPU *cpu, 
Error **errp)
 return;
 }

-/*
- * Shorthand vector crypto extensions
- */
-if (cpu->cfg.ext_zvknc) {
-cpu_cfg_ext_auto_update(cpu, CPU_CFG_OFFSET(ext_zvkn), true);
-cpu_cfg_ext_auto_update(cpu, CPU_CFG_OFFSET(ext_zvbc), true);
-}
-
-if (cpu->cfg.ext_zvkng) {
-cpu_cfg_ext_auto_update(cpu, CPU_CFG_OFFSET(ext_zvkn), true);
-cpu_cfg_ext_auto_update(cpu, CPU_CFG_OFFSET(ext_zvkg), true);
-}
-
-if (cpu->cfg.ext_zvkn) {
-cpu_cfg_ext_auto_update(cpu, CPU_CFG_OFFSET(ext_zvkned), true);
-cp

Re: [patch] debuginfod metadata extension

[Frank Ch. Eigler]

Hi -

> Thanks for the patch, some suggestions below.

Thanks, adding the following 'git diff -w' to the patch you reviewed:

> [...]
> I was experimenting with metadata queries to a local server that indexed
> a single rpm (binutils-2.41-8.fc40.x86_64.rpm). The following commands
> produced JSON with empty "results":
> 
> debuginfod-find metadata glob '*'
> debuginfod-find metadata glob '/usr*'
> debuginfod-find metadata glob '/usr/bin*'
> 
> Using the glob '/usr/bin/*' did produce results with complete metadata.
> 
> I haven't looked into the cause but this seems like a bug.  I'd expect
> the first 3 globs to return at least as many results as the 4th. If this is
> intentional behaviour then I think it should be documented.

This is intentional.  When you use glob patterns like '*' or '/usr*'
in the shell, you don't get recursive path name lists either.
Addressed in the documentation via reference to shell /
fnmatch(FNM_PATHNAME).


diff --git a/debuginfod/debuginfod-client.c b/debuginfod/debuginfod-client.c
index c75abadf7dce..3d6f8d8c4bea 100644
--- a/debuginfod/debuginfod-client.c
+++ b/debuginfod/debuginfod-client.c
@@ -72,7 +72,7 @@ int debuginfod_find_section (debuginfod_client *c, const 
unsigned char *b,
 int s, const char *scn, char **p)
  { return -ENOSYS; }
 int debuginfod_find_metadata (debuginfod_client *c,
-  const char *k, char *v, char **p) { return 
-ENOSYS; }
+  const char *k, const char *v, char **p) { return 
-ENOSYS; }
 void debuginfod_set_progressfn(debuginfod_client *c,
   debuginfod_progressfn_t fn) { }
 void debuginfod_set_verbose_fd(debuginfod_client *c, int fd) { }
@@ -858,22 +858,12 @@ init_server_urls(char* url_subdir, const char* type,
   char *server_url = strtok_r(server_urls, url_delim, _saveptr);
   /* Count number of URLs.  */
   int n = 0;
-  assert (0 == strcmp(url_subdir, "buildid") || 0 == strcmp(url_subdir, 
"metadata"));
 
   while (server_url != NULL)
 {
-  int r;
-  char *tmp_url;
-  if (strlen(server_url) > 1 && server_url[strlen(server_url)-1] == '/')
-r = asprintf(_url, "%s%s", server_url, url_subdir);
-  else
-r = asprintf(_url, "%s/%s", server_url, url_subdir);
-
-  if (r == -1)
-return -ENOMEM;
-
-  // When we encounted a (well-formed) token off the form ima:foo, we 
update the policy
-  // under which results from that server will be ima verified
+  // When we encountered a (well-formed) token off the form
+  // ima:foo, we update the policy under which results from that
+  // server will be ima verified
   if (startswith(server_url, "ima:"))
 {
 #ifdef ENABLE_IMA_VERIFICATION
@@ -898,6 +888,17 @@ init_server_urls(char* url_subdir, const char* type,
   goto continue_next_url;
 }
 
+  // Construct actual URL for libcurl
+  int r;
+  char *tmp_url;
+  if (strlen(server_url) > 1 && server_url[strlen(server_url)-1] == '/')
+r = asprintf(_url, "%s%s", server_url, url_subdir);
+  else
+r = asprintf(_url, "%s/%s", server_url, url_subdir);
+
+  if (r == -1)
+return -ENOMEM;
+  
   /* PR 27983: If the url is duplicate, skip it */
   int url_index;
   for (url_index = 0; url_index < n; ++url_index)
@@ -1025,7 +1026,7 @@ init_handle(debuginfod_client *client,
 
 /*
  * This function busy-waits on one or more curl queries to complete. This can
- * be controled via only_one, which, if true, will find the first winner and 
exit
+ * be controlled via only_one, which, if true, will find the first winner and 
exit
  * once found. If positive maxtime and maxsize dictate the maximum allowed 
wait times
  * and download sizes respectively. Returns 0 on success and -Posix error on 
failure.
  */
@@ -1044,7 +1045,7 @@ perform_queries(CURLM *curlm, CURL **target_handle, 
struct handle_data *data, de
   c->winning_headers = NULL;
 }
   if (maxtime > 0 && clock_gettime(CLOCK_MONOTONIC_RAW, _time) == -1)
-return errno;
+return -errno;
   long delta = 0;
   do
 {
@@ -1052,7 +1053,7 @@ perform_queries(CURLM *curlm, CURL **target_handle, 
struct handle_data *data, de
   if (maxtime > 0)
 {
   if (clock_gettime(CLOCK_MONOTONIC_RAW, _time) == -1)
-return errno;
+return -errno;
   delta = cur_time.tv_sec - start_time.tv_sec;
   if ( delta >  maxtime)
 {
@@ -1108,9 +1109,7 @@ perform_queries(CURLM *curlm, CURL **target_handle, 
struct handle_data *data, de
 }
   
   long dl_size = -1;
-  if (only_one && target_handle)
-{ // Only bother with progress functions if we're retrieving exactly 1 
file
-  if (*target_handle && (c->progressfn || maxsize > 0))
+  if (target_handle && *target_handle && (c->progressfn || maxsize > 0))
 {
   /* Get 

Re: [COOT] Custom pop-up windows

[Frank Von Delft]

Hi Marko, I meant: you asked for an example, and pandda.inspect is an example. 
HTH

Sent from tiny silly touch screen


From: Marko Hyvonen 
Sent: Friday, 31 May 2024 17:13
To: COOT@JISCMAIL.AC.UK
Subject: Re: [COOT] Custom pop-up windows

Yes, I know Frank, but wanted to have something standalone for 
non-pandda-enabled (is that a word?) projects and including not just “Ligands” 
or “events”, but any attention-seeking site in my structure. If your guys can 
help to pull out the bit of code that does panda-inspect, would be a step 
forward.

Paul, Eta, yes, I know Ctrl-G, but I still need to type the residues.  I am 
hoping to have something that does not require me (or someone else) to recall 
what and where to check. With tens of structures in some cases, with 8 active 
sites, 4 allosteric sites, crappy bits to check, my old brain needs a “check 
list” to click through to make sure I i) check all the sites and ii) don’t 
spend extra time doing navigating rather than staring at the density. If I 
could just hit a space bar to flick through that list (like happens with “Go to 
(Next) Ligand” button), even better.

Cheers, Marko

From: Frank Von Delft 
Sent: Friday, May 31, 2024 11:17 AM
To: Marko Hyvonen 
Subject: Re: [COOT] Custom pop-up windows

panda.inspect does this

Sent from tiny silly touch screen

From: Marko Hyvonen mailto:mh...@cam.ac.uk>>
Sent: Friday, 31 May 2024 09:07
To: COOT@JISCMAIL.AC.UK<mailto:COOT@JISCMAIL.AC.UK>
Subject: [COOT] Custom pop-up windows


Hello all,

Would anyone have a template/example to create a custom pop-up window (a bit 
like “Go to atom….” one) for Coot?  We’d like to have something to help to 
browse through a large number of sizeable structures (oligomeric protein, 
several ligand sites, problematic loops, fair few other sites of “interest”)  
as using Go To Atom selection gets a little tiring after a while.

What I’d like to have is

·a custom menu item in Coot

·that pops up a new window

·with a list of all the available molecules (and maps, ideally)

·and buttons to navigate different site (defined by residues, for 
example).

A bit like a customised “Go to atom…” navigation window, if you like: “Browse 
the sites of interest”

I have managed creation of a custom menus with a scheme script on startup, but 
this pop-up window idea has resisted my poor scripting/programming skills.

Any advice & help much appreciated.

Cheers, Marko

-
Marko Hyvönen
Department of Biochemistry
University of Cambridge
mh...@cam.ac.uk<mailto:mh...@cam.ac.uk>
https://hyvonen.bioc.cam.ac.uk<https://hyvonen.bioc.cam.ac.uk/>
@HyvonenGroup




To unsubscribe from the COOT list, click the following link:
https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=COOT=1



To unsubscribe from the COOT list, click the following link:
https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=COOT=1



To unsubscribe from the COOT list, click the following link:
https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=COOT=1

This message was issued to members of www.jiscmail.ac.uk/COOT, a mailing list 
hosted by www.jiscmail.ac.uk, terms & conditions are available at 
https://www.jiscmail.ac.uk/policyandsecurity/

Re: [PATCH v4 05/12] dmaengine: Add STM32 DMA3 support

[Frank Li]

On Fri, May 31, 2024 at 05:07:05PM +0200, Amelie Delaunay wrote:
> STM32 DMA3 driver supports the 3 hardware configurations of the STM32 DMA3
> controller:
> - LPDMA (Low Power): 4 channels, no FIFO
> - GPDMA (General Purpose): 16 channels, FIFO from 8 to 32 bytes
> - HPDMA (High Performance): 16 channels, FIFO from 8 to 256 bytes
> Hardware configuration of the channels is retrieved from the hardware
> configuration registers.
> 
> The client can specify its channel requirements through device tree.
> STM32 DMA3 channels can be individually reserved either because they are
> secure, or dedicated to another CPU.
> Indeed, channels availability depends on Resource Isolation Framework
> (RIF) configuration. RIF grants access to buses with Compartment ID (CID)
> filtering, secure and privilege level. It also assigns DMA channels to one
> or several processors.
> DMA channels used by Linux should be CID-filtered and statically assigned
> to CID1 or shared with other CPUs but using semaphore. In case CID
> filtering is not configured, dma-channel-mask property can be used to
> specify available DMA channels to the kernel, otherwise such channels
> will be marked as reserved and can't be used by Linux.
> 
> STM32 DMA3 is a new STM32 DMA controller, not a new version of an existing
> one.
> stm32-dma is not considered for reuse because register layout is completely
> different and doesn't rely on descriptors mechanism.
> stm32-mdma is based on descriptors mechanism but there are significant
> differences in register layout and descriptors structure.
> 
> Signed-off-by: Amelie Delaunay 
> ---
> v4:
> - align comments alignment in enum definition
> - use __packed for stm32_dma3_hwdesc structure
> - use generic dma_wmb() instead of __iowmb()
> v3:
> - fix typo in commit message (Compartment)
> - add a paragraph in commit message to explain why stm32-dma and stm32-mdma
>   are not reused
> - add explicit write memory barrier on the last descriptor initialization
> v2:
> - lowercase in hex values
> - compatible has been updated to st,stm32mp25-dma3 (SoC specific)
> ---
>  drivers/dma/stm32/Kconfig  |   10 +
>  drivers/dma/stm32/Makefile |1 +
>  drivers/dma/stm32/stm32-dma3.c | 1440 
>  3 files changed, 1451 insertions(+)
>  create mode 100644 drivers/dma/stm32/stm32-dma3.c
> 
> diff --git a/drivers/dma/stm32/Kconfig b/drivers/dma/stm32/Kconfig
> index b72ae1a4502f..4d8d8063133b 100644
> --- a/drivers/dma/stm32/Kconfig
> +++ b/drivers/dma/stm32/Kconfig
> @@ -34,4 +34,14 @@ config STM32_MDMA
> If you have a board based on STM32 SoC with such DMA controller
> and want to use MDMA say Y here.
>  
> +config STM32_DMA3
> + tristate "STMicroelectronics STM32 DMA3 support"
> + select DMA_ENGINE
> + select DMA_VIRTUAL_CHANNELS
> + help
> +   Enable support for the on-chip DMA3 controller on STMicroelectronics
> +   STM32 platforms.
> +   If you have a board based on STM32 SoC with such DMA3 controller
> +   and want to use DMA3, say Y here.
> +
>  endif
> diff --git a/drivers/dma/stm32/Makefile b/drivers/dma/stm32/Makefile
> index 663a3896a881..5082db4b4c1c 100644
> --- a/drivers/dma/stm32/Makefile
> +++ b/drivers/dma/stm32/Makefile
> @@ -2,3 +2,4 @@
>  obj-$(CONFIG_STM32_DMA) += stm32-dma.o
>  obj-$(CONFIG_STM32_DMAMUX) += stm32-dmamux.o
>  obj-$(CONFIG_STM32_MDMA) += stm32-mdma.o
> +obj-$(CONFIG_STM32_DMA3) += stm32-dma3.o
> diff --git a/drivers/dma/stm32/stm32-dma3.c b/drivers/dma/stm32/stm32-dma3.c
> new file mode 100644
> index ..49886117d29b
> --- /dev/null
> +++ b/drivers/dma/stm32/stm32-dma3.c
> @@ -0,0 +1,1440 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * STM32 DMA3 controller driver
> + *
> + * Copyright (C) STMicroelectronics 2024
> + * Author(s): Amelie Delaunay 
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include "../virt-dma.h"
> +
> +#define STM32_DMA3_SECCFGR   0x00
> +#define STM32_DMA3_PRIVCFGR  0x04
> +#define STM32_DMA3_RCFGLOCKR 0x08
> +#define STM32_DMA3_MISR  0x0c
> +#define STM32_DMA3_SMISR 0x10
> +
> +#define STM32_DMA3_CLBAR(x)  (0x50 + 0x80 * (x))
> +#define STM32_DMA3_CCIDCFGR(x)   (0x54 + 0x80 * (x))
> +#define STM32_DMA3_CSEMCR(x) (0x58 + 0x80 * (x))
> +#define STM32_DMA3_CFCR(x)   (0x5c + 0x80 * (x))
> +#define STM32_DMA3_CSR(x)(0x60 + 0x80 * (x))
> +#define STM32_DMA3_CCR(x)(0x64 + 0x80 * (x))
> +#define STM32_DMA3_CTR1(x)   (0x90 + 0x80 * (x))
> +#define STM32_DMA3_CTR2(x)   (0x94 + 0x80 * (x))
> +#define STM32_DMA3_CBR1(x)   (0x98 + 0x80 * (x))
> +#define STM32_DMA3_CSAR(x)   (0x9c + 0x80 * (x))
> +#define STM32_DMA3_CDAR(x)   (0xa0 + 0x80 * (x))
> +#define 

[ia64] Results for 15.0.0 20240528 (experimental) [master revision 236116068151bbc72aaaf53d0f223fe06f7e3bac] (GCC) w/LRA testsuite on ia64-t2-linux-gnu

[Frank Scheiner via Gcc-testresults]

in
/dev/shm/gcc-15-lra/src.gcc.ia64-toolchain-3.240529.123346.921189/gcc/gcc.build.lnx/gcc



date; time make -j4 check-gcc 2>&1; echo $?; date
Fri May 31 11:48:35 UTC 2024

=== gcc tests ===

Running target unix
FAIL: gcc.c-torture/compile/attr-retain-1.c   -O0   scan-assembler
.rodata.*,"aR"
FAIL: gcc.c-torture/compile/attr-retain-1.c   -O1   scan-assembler
.bss.*,"awR"
FAIL: gcc.c-torture/compile/attr-retain-1.c   -O1   scan-assembler
.rodata.*,"aR"
FAIL: gcc.c-torture/compile/attr-retain-1.c   -O2   scan-assembler
.bss.*,"awR"
FAIL: gcc.c-torture/compile/attr-retain-1.c   -O2   scan-assembler
.rodata.*,"aR"
FAIL: gcc.c-torture/compile/attr-retain-1.c   -O3 -g   scan-assembler
.bss.*,"awR"
FAIL: gcc.c-torture/compile/attr-retain-1.c   -O3 -g   scan-assembler
.rodata.*,"aR"
FAIL: gcc.c-torture/compile/attr-retain-1.c   -Os   scan-assembler
.bss.*,"awR"
FAIL: gcc.c-torture/compile/attr-retain-1.c   -Os   scan-assembler
.rodata.*,"aR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -O0   scan-assembler
.bss.used_bss,"awR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -O0   scan-assembler
.bss.used_bss2,"awR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -O0   scan-assembler
.data.used_data,"awR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -O0   scan-assembler
.data.used_data2,"awR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -O0   scan-assembler
.rodata.used_rodata,"aR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -O0   scan-assembler
.rodata.used_rodata2,"aR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -O1   scan-assembler
.bss.used_bss,"awR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -O1   scan-assembler
.bss.used_bss2,"awR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -O1   scan-assembler
.data.used_data,"awR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -O1   scan-assembler
.data.used_data2,"awR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -O1   scan-assembler
.rodata.used_rodata,"aR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -O1   scan-assembler
.rodata.used_rodata2,"aR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -O2   scan-assembler
.bss.used_bss,"awR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -O2   scan-assembler
.bss.used_bss2,"awR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -O2   scan-assembler
.data.used_data,"awR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -O2   scan-assembler
.data.used_data2,"awR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -O2   scan-assembler
.rodata.used_rodata,"aR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -O2   scan-assembler
.rodata.used_rodata2,"aR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -O3 -g   scan-assembler
.bss.used_bss,"awR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -O3 -g   scan-assembler
.bss.used_bss2,"awR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -O3 -g   scan-assembler
.data.used_data,"awR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -O3 -g   scan-assembler
.data.used_data2,"awR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -O3 -g   scan-assembler
.rodata.used_rodata,"aR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -O3 -g   scan-assembler
.rodata.used_rodata2,"aR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -Os   scan-assembler
.bss.used_bss,"awR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -Os   scan-assembler
.bss.used_bss2,"awR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -Os   scan-assembler
.data.used_data,"awR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -Os   scan-assembler
.data.used_data2,"awR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -Os   scan-assembler
.rodata.used_rodata,"aR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -Os   scan-assembler
.rodata.used_rodata2,"aR"
FAIL: gcc.c-torture/compile/pr29201.c   -O0  (test for excess errors)
FAIL: gcc.c-torture/compile/pr29201.c   -O1  (test for excess errors)
FAIL: gcc.c-torture/compile/pr29201.c   -O2  (test for excess errors)
FAIL: gcc.c-torture/compile/pr29201.c   -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions  (test for
excess errors)
FAIL: gcc.c-torture/compile/pr29201.c   -O3 -g  (test for excess errors)
FAIL: gcc.c-torture/compile/pr29201.c   -Os  (test for excess errors)
WARNING: program timed out
FAIL: gcc.c-torture/compile/limits-blockid.c   -O3 -g  (test for excess
errors)
FAIL: gcc.c-torture/execute/pr64242.c   -O0  execution test
FAIL: gcc.c-torture/execute/pr64242.c   -O1  execution test
FAIL: gcc.c-torture/execute/pr64242.c   -O2  execution test
FAIL: gcc.c-torture/execute/pr64242.c   -O3 -g  execution test
FAIL: gcc.c-torture/execute/pr64242.c   -Os  execution test
FAIL: gcc.c-torture/execute/pr84521.c   -O0  execution test
FAIL: gcc.c-torture/execute/pr84521.c   -O1  execution test
FAIL: gcc.c-torture/execute/pr84521.c   -O2  execution test
FAIL: gcc.c-torture/execute/pr84521.c   -O3 -g  execution test
FAIL: gcc.c-torture/execute/pr84521.c   -Os  execution test
FAIL: gcc.dg/atomic/c11-atomic-exec-5.c   -O0  execution test
FAIL: gcc.dg/atomic/c11-atomic-exec-5.c  

[FRIAM] Come please

[Frank Wimberly]

I'm at Downtown Subscription trying to hold a table for the group.  At 9:40
no one else has come.  I resolve not to be the first to arrive anymore.

---
Frank C. Wimberly
140 Calle Ojo Feliz,
Santa Fe, NM 87505

505 670-9918
Santa Fe, NM
-. --- - / ...- .- .-.. .. -.. / -- --- .-. ... . / -.-. --- -.. .
FRIAM Applied Complexity Group listserv
Fridays 9a-12p Friday St. Johns Cafe   /   Thursdays 9a-12p Zoom 
https://bit.ly/virtualfriam
to (un)subscribe http://redfish.com/mailman/listinfo/friam_redfish.com
FRIAM-COMIC http://friam-comic.blogspot.com/
archives:  5/2017 thru present https://redfish.com/pipermail/friam_redfish.com/
  1/2003 thru 6/2021  http://friam.383.s1.nabble.com/

Re: [FRIAM] Objective Reality Doesn’t Exist. We’ve Known This for a Century. It’s Time to Embrace It and Move On. | by Casper Wilstrup | Machine Consciousness | Medium

[Frank Wimberly]

It exists in my mind.  Joke.

---
Frank C. Wimberly
140 Calle Ojo Feliz,
Santa Fe, NM 87505

505 670-9918
Santa Fe, NM

On Fri, May 31, 2024, 8:59 AM Nicholas Thompson 
wrote:

> This (see below) got served up to me out of the blue this morning.  The
> way it's put here, Frank and Bruce might actually agree with it.  Still,
> it's straight Peirce.  I have no idea who the author is; do any of you?
>
> Here's crucial passage.
>
> *Our understanding of reality needs a complete overhaul. Rather than
> viewing it as a fixed, external stage upon which events play out, we should
> consider it as a dynamic interplay between observers and their
> environment [*experiences*]. Reality, in this view, doesn’t reside out
> there, independent of us. Instead, reality is our interactions with the
> world  [*one another*], shaped and defined by our observations [*
> experiences*]. Reality is nothing but [*the telos of*] those interactions
> between subjects.*
>
> I had to make those little changes because the author,  like so many
> aspiring monists, after arguing against observer independence for a hundred
> words, slips up by implying that the "environment" is anything but
> something else that we have to agree upon, if we are ever going to get on
> with life.
>
> By the way,  I stipulate that nothing in his argument has ANYTHING to do
> with quantum mechanics. The argument would be sound even if the idea of a
> quantum had never been thought.  However, I like the idea of physics as
> some kind of language of convergent belief.
>
> By the way,  In history there seem to have been two ways for people
> converge on a common experience, charisma and democracy.  In charisma, we
> pick some idiot (usually a psychopath) and share his or her experience.  In
> democracy, we find  some way to blend our experiences into a common view.
> Sometime in the next few months we will decide which way we want to go.
>  Do we want to assign Trump the job of determining our common reality, or
> do we want to continue to work it out amongst ourselves through experiment
> and argument.
>
> Weather gorgeous here in the mosquito infested swamp.  Garden thriving.  A
> much better year.
>
> Watch that dry line in TX.  It's truly amazing.  Can it really be true
> that I am the only weather fanatic on a list that is devoted to
> complexity?   How can that be?
>
> NIck
>
>
>
>
> https://medium.com/machine-cognition/objective-reality-doesnt-exist-it-is-time-to-accept-it-and-move-on-7524b494d6af
>
> <https://medium.com/machine-cognition/objective-reality-doesnt-exist-it-is-time-to-accept-it-and-move-on-7524b494d6af>
> Objective Reality Doesn’t Exist: It is Time to Embrace it and Move On
> <https://medium.com/machine-cognition/objective-reality-doesnt-exist-it-is-time-to-accept-it-and-move-on-7524b494d6af>
> The shift towards a unified, observer-dependent reality forces us to let
> go — once and for all — of the idea of objective reality
> medium.com
>
>
>
> -. --- - / ...- .- .-.. .. -.. / -- --- .-. ... . / -.-. --- -.. .
> FRIAM Applied Complexity Group listserv
> Fridays 9a-12p Friday St. Johns Cafe   /   Thursdays 9a-12p Zoom
> https://bit.ly/virtualfriam
> to (un)subscribe http://redfish.com/mailman/listinfo/friam_redfish.com
> FRIAM-COMIC http://friam-comic.blogspot.com/
> archives:  5/2017 thru present
> https://redfish.com/pipermail/friam_redfish.com/
>   1/2003 thru 6/2021  http://friam.383.s1.nabble.com/
>
-. --- - / ...- .- .-.. .. -.. / -- --- .-. ... . / -.-. --- -.. .
FRIAM Applied Complexity Group listserv
Fridays 9a-12p Friday St. Johns Cafe   /   Thursdays 9a-12p Zoom 
https://bit.ly/virtualfriam
to (un)subscribe http://redfish.com/mailman/listinfo/friam_redfish.com
FRIAM-COMIC http://friam-comic.blogspot.com/
archives:  5/2017 thru present https://redfish.com/pipermail/friam_redfish.com/
  1/2003 thru 6/2021  http://friam.383.s1.nabble.com/

Re: [FRIAM] Downtown Subscription

[Frank Wimberly]

Reminder.  They can't possibly have finished the construction.

---
Frank C. Wimberly
140 Calle Ojo Feliz,
Santa Fe, NM 87505

505 670-9918
Santa Fe, NM

On Thu, May 30, 2024, 4:48 PM Marcus Daniels  wrote:

> If LLM training has reached a zero loss on a corpus that happens to
> include these, it should be able to do a decent job of mimicking their
> style and content.
>
> I expect many disreputable sources have been processed, along with
> critical review material arguing that.
>
>
>
> *From:* Friam  *On Behalf Of *Prof David West
> *Sent:* Thursday, May 30, 2024 11:59 AM
> *To:* Stephen Guerin ; The Friday Morning
> Applied Complexity Coffee Group 
> *Subject:* Re: [FRIAM] words
>
>
>
> I share at least a hue of Steve's thralldom.
>
>
>
> As Marcus noted, "it depends on the training set." If Howard (as an LLM)
> was trained on the contents of the Embassy of the Free Mind in Amsterdam
> nothing he says would be a surprise. [The Embassy is a library with all
> things Alchemical.] I do not know about DaVinci, but if Howard and Newton
> (considered the last great Alchemist) engaged in a conversation they might
> disagree, but I do think they would "understand" each other. (Talking about
> the flower of life, platonic solids, etc. NOT natal memory.)
>
>
>
> It would be interesting to see what Open AI's training set entails. Does
> it include or exclude the "disreputable" the "pseudo-scientific?" Does in
> include much non-Western philosophy; especially in the areas of
> epistemology and metaphysics?
>
>
>
> There is little need to call bullshit, at least in the modern Western
> world, because sufficient forces already exist to marginalize any
> contrarian, in almost every aspect of life.
>
>
>
> davew
>
>
>
>
>
> On Thu, May 30, 2024, at 12:52 PM, Stephen Guerin wrote:
>
> *prompt: * You are Terrance Howard. Make 3 revolutionary claims that will
> enable a general unified theory of Complexity Science.
>
>
>
> *4o:*  As Terrence Howard, here are three revolutionary claims that will
> enable a general unified theory of Complexity Science, with one relating to
> understanding the world as computation:
>
>
>
> 1. **Revolutionary Geometry and Mathematics**:
>
>"I have developed a new geometric framework that redefines the
> fundamental constants and principles of mathematics. By understanding that
> 1 x 1 = 2, we can break free from traditional mathematical constraints and
> uncover deeper truths about the universe's structure. This new geometry,
> based on my studies of Terryology, reveals hidden dimensions and
> interactions that were previously invisible to us, providing a holistic
> view of complex systems and their emergent properties."
>
>
>
> 2. **Unified Field Theory through Vibrational Harmonics**:
>
>"By exploring the vibrational harmonics that govern atomic and
> subatomic interactions, I have formulated a Unified Field Theory that links
> quantum mechanics and general relativity. This theory posits that all
> matter and energy are manifestations of underlying wave patterns, which can
> be tuned and manipulated to create new forms of energy and matter. This
> understanding allows us to predict and control complex behaviors in
> physical, biological, and even social systems, leading to breakthroughs in
> energy production, medical treatments, and societal organization."
>
>
>
> 3. **World as Computation - Universal Compiler**:
>
>"The universe operates as a vast computational substrate, where every
> particle and wave functions as part of a grand computation. I have
> developed a Universal Compiler, capable of interpreting and executing any
> script on this cosmic computational substrate. This compiler translates
> abstract mathematical theories, physical laws, and biological processes
> into executable programs, enabling us to simulate and manipulate reality at
> an unprecedented level. By leveraging this technology, we can solve complex
> problems, optimize systems for efficiency, and unlock new realms of
> scientific and technological innovation."
>
>
>
> These claims, if validated and accepted, would revolutionize Complexity
> Science by providing new tools and perspectives to understand and
> manipulate the intricate web of interactions that define our universe.
>
>
>
> -S
>
>
>
> ps I biased the third one.
>
>
>
> On Thu, May 30, 2024 at 11:41 AM Stephen Guerin <
> stephen.gue...@simtable.com> wrote:
>
> In this LLM era, where many people, including some on this list, are
> enthralled by random bullshit
>
>
>
> Color me enthralled 
>
>

[users] Re: Linux distribution

[Frank Bendon via Users]

Hello again Martin
I was following the procedure in
https://chirpmyradio.com/projects/chirp/wiki/ChirpOnLinux
which uses pipx.
Answering your questions:
The system is running Ubuntu-mate 20.04 and I it is the first time
I have tried to get it working. .
I did not keep any of the error messages and don't want to try again
- takes too long to clean up the mess
The next thing I want to try is to set up a clean virtual machine and
try installing it on that.
Has anyone had any success with running the windows binary in
wine?

Cheers
Frank
VK5BF


On 30/5/24 23:51, Martin Cooper via Users wrote:

Hi Frank,

Are you using pipx, or pip? You mentioned "despite pip saying they were
already installed", which is why I ask. You need to use pipx. pipx sets up
an isolated environment for Chirp to run in, with the dependencies
installed in that environment. This is to avoid conflicts between Chirp and
other Python software you may have installed. If you then use pip to see if
dependencies are installed, you will be looking at a different environment,
and not the one that pipx created for Chirp.

It would be helpful to see a log of what you're typing on your terminal,
and the output that you're seeing. If it is really "pages full of
complaints", then you could either post the beginning and end, or capture
everything in a log file and attach that to your e-mail.

It might also be helpful if you could tell us which Linux distro and
version you are using, and whether this is a first-time Chirp install, or
whether you've had older versions of Chirp installed on the same system
(remnants of which may still be hanging around).

Thanks,

Martin.
KD6YAM

On Thu, May 30, 2024 at 6:34 AM Frank Bendon via Users <
users@lists.chirpmyradio.com> wrote:


Hi Martin
Thanks for the reply.  I went through the "ChirpOnLinux" procedure but
just get pages full of complaints about missing modules despite pip
saying they were already installed - at least all the ones I tried.  The
version in the debian repository hangs when trying to download from a
radio, it is probably quite old.   I would prefer a static binary - it
would be more reliable.

Cheers
Frank
VK5BF

On 30/5/24 12:42 am, Martin Cooper via Users wrote:

Hi Frank,

Assuming you are following the instructions here (linked from the

Downloads

page):

https://chirpmyradio.com/projects/chirp/wiki/ChirpOnLinux

what "failed dependencies" are you seeing?

Martin.
KD6YAM

On Wed, May 29, 2024 at 6:32 AM Frank via Users <
users@lists.chirpmyradio.com> wrote:


Is there an appImage (compiled) version of Chirp available?  - for the
various versions of linux.Both the .whl and tar.gz versions

currently

on the chirp website do not work (failed dependencies)
___
Users mailing list
users@lists.chirpmyradio.com


https://lists.chirpmyradio.com/postorius/lists/users.lists.chirpmyradio.com

To unsubscribe, send an email to users-le...@lists.chirpmyradio.com
To report this email as off-topic, please email
users-ow...@lists.chirpmyradio.com
List archives:


https://lists.chirpmyradio.com/hyperkitty/list/users@lists.chirpmyradio.com/

___
Users mailing list
users@lists.chirpmyradio.com


https://lists.chirpmyradio.com/postorius/lists/users.lists.chirpmyradio.com

To unsubscribe, send an email to users-le...@lists.chirpmyradio.com
To report this email as off-topic, please email

users-ow...@lists.chirpmyradio.com

List archives:

https://lists.chirpmyradio.com/hyperkitty/list/users@lists.chirpmyradio.com/
___
Users mailing list
users@lists.chirpmyradio.com
https://lists.chirpmyradio.com/postorius/lists/users.lists.chirpmyradio.com
To unsubscribe, send an email to users-le...@lists.chirpmyradio.com
To report this email as off-topic, please email
users-ow...@lists.chirpmyradio.com
List archives:
https://lists.chirpmyradio.com/hyperkitty/list/users@lists.chirpmyradio.com/

___
Users mailing list
users@lists.chirpmyradio.com
https://lists.chirpmyradio.com/postorius/lists/users.lists.chirpmyradio.com
To unsubscribe, send an email to users-le...@lists.chirpmyradio.com
To report this email as off-topic, please email 
users-ow...@lists.chirpmyradio.com
List archives: 
https://lists.chirpmyradio.com/hyperkitty/list/users@lists.chirpmyradio.com/

___
Users mailing list
users@lists.chirpmyradio.com
https://lists.chirpmyradio.com/postorius/lists/users.lists.chirpmyradio.com
To unsubscribe, send an email to users-le...@lists.chirpmyradio.com
To report this email as off-topic, please email 
users-ow...@lists.chirpmyradio.com
List archives: 
https://lists.chirpmyradio.com/hyperkitty/list/users@lists.chirpmyradio.com/

Re: [PATCH 3/6] dt-bindings: gpu: powervr-rogue: Add MediaTek MT8173 GPU

[Frank Binns]

Hi ChenYu,

On Thu, 2024-05-30 at 16:35 +0800, Chen-Yu Tsai wrote:
> The MediaTek MT8173 comes with a PowerVR Rogue GX6250, which is one
> of the Series6XT GPUs, another sub-family of the Rogue family.

I've added Adam Ford who sent out some DT related patches [1] for the Renesas
variant of GX6250 and the GX6650 (another Series6XT GPU).

> 
> This was part of the very first few versions of the PowerVR submission,
> but was later dropped. The compatible string has been updated to follow
> the new naming scheme adopted for the AXE series.
> 
> In a previous iteration of the PowerVR binding submission [1], the
> number of clocks required for the 6XT family was mentioned to be
> always 3. This is also reflected here.
> 
> [1] 
> https://lore.kernel.org/dri-devel/6eeccb26e09aad67fb30ffcd523c793a43c79c2a.ca...@imgtec.com/
> 
> Signed-off-by: Chen-Yu Tsai 
> ---
>  .../bindings/gpu/img,powervr-rogue.yaml   | 24 +++
>  1 file changed, 20 insertions(+), 4 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/gpu/img,powervr-rogue.yaml 
> b/Documentation/devicetree/bindings/gpu/img,powervr-rogue.yaml
> index 256e252f8087..48aa205b66b4 100644
> --- a/Documentation/devicetree/bindings/gpu/img,powervr-rogue.yaml
> +++ b/Documentation/devicetree/bindings/gpu/img,powervr-rogue.yaml
> @@ -12,10 +12,17 @@ maintainers:
>  
>  properties:
>compatible:
> -items:
> -  - enum:
> -  - ti,am62-gpu
> -  - const: img,img-axe # IMG AXE GPU model/revision is fully discoverable
> +oneOf:
> +  - items:
> +  - enum:
> +  - mediatek,mt8173-gpu
> +  # PowerVR 6XT GPU model/revision is fully discoverable
> +  - const: img,powervr-6xt
> +  - items:
> +  - enum:
> +  - ti,am62-gpu
> +  # IMG AXE GPU model/revision is fully discoverable
> +  - const: img,img-axe

The Series6XT GPU models have differing numbers of power domains (either 2, 4 or
5). Whereas, the AXE GPUs have a single power domain, so I assume there should
be a related change here.

The GX6250 has two power domains (lets call them A and B). There's a constraint
that if domain B is powered then domain A must also be powered.

In patch 6 [2] it's setting the power domain to MT8173_POWER_DOMAIN_MFG, which I
believe corresponds to power domain B. I assume this works because the MTK power
controller driver is encoding the constraint above, meaning that when we disable
or enable MT8173_POWER_DOMAIN_MFG it's also disabling/enabling MT8173_POWER_DOMA
IN_MFG_2D (domain A).

Thanks
Frank

[1] https://lists.freedesktop.org/archives/dri-devel/2024-February/443548.html
[2] https://lists.freedesktop.org/archives/dri-devel/2024-May/455833.html

>  
>reg:
>  maxItems: 1
> @@ -56,6 +63,15 @@ allOf:
>properties:
>  clocks:
>maxItems: 1
> +  - if:
> +  properties:
> +compatible:
> +  contains:
> +const: img,powervr-6xt
> +then:
> +  properties:
> +clocks:
> +  minItems: 3
>  
>  examples:
>- |

[FFmpeg-devel] [PATCH] lavc/vvc: Don't free uninitialised pic arrays

[Frank Plowman]

The picture arrays are not initialised at the same time as the frame
context itself, but rather when the relevant frame begins being decoded.
As such, situations can arise where the frame context is being freed but
the picture arrays have not yet been initialised.  This could lead to
various UB and ultimately crashes.  Patch prevents this by adding an
initialised flag associated with the picture arrays.

Signed-off-by: Frank Plowman 
---
 libavcodec/vvc/dec.c | 7 +++
 libavcodec/vvc/dec.h | 2 ++
 2 files changed, 9 insertions(+)

diff --git a/libavcodec/vvc/dec.c b/libavcodec/vvc/dec.c
index e53ad4e607..32e5bc0cd8 100644
--- a/libavcodec/vvc/dec.c
+++ b/libavcodec/vvc/dec.c
@@ -327,6 +327,9 @@ static void free_cus(VVCFrameContext *fc)
 
 static void pic_arrays_free(VVCFrameContext *fc)
 {
+if (!fc->tab.initialised)
+return;
+
 free_cus(fc);
 frame_context_for_each_tl(fc, tl_free);
 ff_refstruct_pool_uninit(>rpl_tab_pool);
@@ -380,6 +383,8 @@ static int pic_arrays_init(VVCContext *s, VVCFrameContext 
*fc)
 fc->tab.sz.bs_width   = (fc->ps.pps->width >> 2) + 1;
 fc->tab.sz.bs_height  = (fc->ps.pps->height >> 2) + 1;
 
+fc->tab.initialised = 1;
+
 return 0;
 }
 
@@ -627,6 +632,8 @@ static av_cold int frame_context_init(VVCFrameContext *fc, 
AVCodecContext *avctx
 if (!fc->tu_pool)
 return AVERROR(ENOMEM);
 
+fc->tab.initialised = 0;
+
 return 0;
 }
 
diff --git a/libavcodec/vvc/dec.h b/libavcodec/vvc/dec.h
index 1e0b76f283..1721ba3a15 100644
--- a/libavcodec/vvc/dec.h
+++ b/libavcodec/vvc/dec.h
@@ -212,6 +212,8 @@ typedef struct VVCFrameContext {
 int bs_height;
 int ibc_buffer_width;   ///< IbcBufWidth
 } sz;
+
+int initialised;
 } tab;
 } VVCFrameContext;
 
-- 
2.45.1

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [PATCH 4/6] drm/imagination: Add compatible string entry for Series6XT

[Frank Binns]

On Thu, 2024-05-30 at 16:35 +0800, Chen-Yu Tsai wrote:
> The MediaTek MT8173 comes with a PowerVR Rogue GX6250, which is part
> of the Series6XT, another variation of the Rogue family of GPUs.
> 
> Signed-off-by: Chen-Yu Tsai 
> ---
>  drivers/gpu/drm/imagination/pvr_drv.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/gpu/drm/imagination/pvr_drv.c 
> b/drivers/gpu/drm/imagination/pvr_drv.c
> index 5c3b2d58d766..3d1a933c8303 100644
> --- a/drivers/gpu/drm/imagination/pvr_drv.c
> +++ b/drivers/gpu/drm/imagination/pvr_drv.c
> @@ -1475,6 +1475,7 @@ pvr_remove(struct platform_device *plat_dev)
>  
>  static const struct of_device_id dt_match[] = {
>   { .compatible = "img,img-axe", .data = NULL },
> + { .compatible = "img,powervr-6xt", .data = NULL },

I assume that by adding this to the list of supported devices we're essentially
freezing the existing uapi. This concerns me, as we've not yet started running
Vulkan conformance on any Series6XT GPUs and there's a chance we may need to
make some tweaks.

I'm not really sure what the accepted approach is to hardware enablement /
experimental support. I'm not sure if it's sufficient to hide support behind a
Kconfig option and/or module parameter or whether we just have to hold this
patch back for the time being.

Thanks
Frank

>   {}
>  };
>  MODULE_DEVICE_TABLE(of, dt_match);

Re: [PATCH 2/6] clk: mediatek: Add mt8173-mfgtop driver

[Frank Binns]

p, 0xa0, 0x0800);
> > 
> > Is there any way to retrieve information about what those registers are?
> 
> I asked. They said the project was too long ago, and they could only
> figure out that it had something to do with core switch sequencing and
> delays between each core, which is what I put in the comment there.
> 
> > > +
> > > + return 0;
> > > +}
> > > +
> > > +static int clk_mt8173_mfgtop_power_off(struct generic_pm_domain *domain)
> > > +{
> > > + struct mt8173_mfgtop_data *data = container_of(domain, struct 
> > > mt8173_mfgtop_data, genpd);
> > > +
> > > + /* Magic numbers related to core switch sequence and delays */
> > > + regmap_write(data->regmap, 0xec, 0);
> > > +
> > > + /* drives internal power management */
> > > + clk_disable_unprepare(data->clk_26m);
> > > +
> > > + return 0;
> > > +}
> > > +
> > > +static int clk_mt8173_mfgtop_probe(struct platform_device *pdev)
> > > +{
> > > + struct device *dev = >dev;
> > > + struct device_node *node = dev->of_node;
> > > + struct mt8173_mfgtop_data *data;
> > > + int ret;
> > > +
> > > + data = devm_kzalloc(dev, sizeof(*data), GFP_KERNEL);
> > > + if (!data)
> > > + return -ENOMEM;
> > > +
> > > + platform_set_drvdata(pdev, data);
> > > +
> > > + data->clk_data = mtk_devm_alloc_clk_data(dev, ARRAY_SIZE(mfg_clks));
> > > + if (!data->clk_data)
> > > + return -ENOMEM;
> > > +
> > > + /* MTK clock gates also uses regmap */
> > > + data->regmap = device_node_to_regmap(node);
> > > + if (IS_ERR(data->regmap))
> > > + return dev_err_probe(dev, PTR_ERR(data->regmap), "Failed to 
> > > get regmap\n");
> > > +
> > > + data->child_pd.np = node;
> > > + data->child_pd.args_count = 0;
> > > + ret = of_parse_phandle_with_args(node, "power-domains", 
> > > "#power-domain-cells", 0,
> > > +  >parent_pd);
> > > + if (ret)
> > > + return dev_err_probe(dev, ret, "Failed to parse power 
> > > domain\n");
> > > +
> > > + devm_pm_runtime_enable(dev);
> > > + /*
> > > +  * Do a pm_runtime_resume_and_get() to workaround a possible
> > > +  * deadlock between clk_register() and the genpd framework.
> > > +  */
> > > + ret = pm_runtime_resume_and_get(dev);
> > > + if (ret) {
> > > + dev_err_probe(dev, ret, "Failed to runtime resume 
> > > device\n");
> > > + goto put_of_node;
> > > + }
> > > +
> > > + ret = mtk_clk_register_gates(dev, node, mfg_clks, 
> > > ARRAY_SIZE(mfg_clks),
> > > +  data->clk_data);
> > > + if (ret) {
> > > + dev_err_probe(dev, ret, "Failed to register clock gates\n");
> > > + goto put_pm_runtime;
> > > + }
> > > +
> > > + data->clk_26m = clk_hw_get_clk(data->clk_data->hws[CLK_MFG_26M], 
> > > "26m");
> > > + if (IS_ERR(data->clk_26m)) {
> > > + dev_err_probe(dev, PTR_ERR(data->clk_26m), "Failed to get 
> > > 26 MHz clock\n");
> > > + goto unregister_clks;
> > > + }
> > > +
> > > + ret = of_clk_add_hw_provider(node, of_clk_hw_onecell_get, 
> > > data->clk_data);
> > > + if (ret) {
> > > + dev_err_probe(dev, ret, "Failed to add clk OF provider\n");
> > > + goto put_26m_clk;
> > > + }
> > > +
> > > + data->genpd.name = "mfg_apm";
> > 
> > "mfg-apm" or "mfg-pwr" please!
> 
> Ack.
> 
> > Everything else looks good.
> > 
> > Thanks for taking care of that, I started this work way too much time ago 
> > and
> > realistically I wouldn't have been able to finish it due to time 
> > constraints.
> > 
> > It's great to see that *finally* we can get some GPU upstream on this old 
> > SoC.
> > As its CPUs are really slow, LLVMPipe is quite unusable from a UX 
> > perspective
> > hence its only big issue was the lack of 3D HW acceleration.
> 
> I think there's still more work on the GPU driver side. I was digging
> through the mailing list to find ways to get it running, and evidently
> it doesn't fully support zink yet.

Upstream Mesa is still missing a lot of changes taking the driver up to Vulkan
1.0 on AXE-1-16M, which is the GPU we've mainly been focusing on. This work can
be found in our Mesa repo on FDO GitLab [1]. Support for GX6250 (Series 6XT) and
BXS-4-64 is currently incomplete (these are the other GPUs we've been adding
support for [2]).

The changes haven't made it upstream yet as we're in the process of reworking
the compiler and compiler/driver interface side of things to address the
inevitable comments we'd get as part of upstreaming. This work should be
complete soon and will go a long way towards improving support for / making it
easier to support more GPUs on the compiler side.

In parallel to this, we've implemented the Vulkan extensions, optional features,
etc needed by Zink [2] and we're currently fixing GLES conformance issues.
Again, we've been focusing on AXE-1-16M. Once we've got GLES conformance passing
we'll be switching our focus to completing support for the BXS-4-64.

Thanks
Frank

[1] https://gitlab.freedesktop.org/imagination/mesa/-/tree/powervr-mesa-next
[2] https://docs.mesa3d.org/drivers/powervr.html
[3] https://gitlab.freedesktop.org/imagination/mesa/-/tree/dev/zink

> 
> > This makes machines embedding this SoC usable, and that's simply awesome.
> 
> I'll give the patches a week to simmer while I go work on some
> other stuff.
> 
> ChenYu

Re: [PATCH 0/6] powervr: MT8173 GPU support

[Frank Binns]

Hi ChenYu,

On Fri, 2024-05-31 at 12:00 +0800, Chen-Yu Tsai wrote:
> On Thu, May 30, 2024 at 4:35 PM Chen-Yu Tsai  wrote:
> > Hi everyone,
> > 
> > This series enables the PowerVR GPU found in the MT8173 SoC, found in
> > some Chromebooks.

Thank you for the patches, I'm really happy to see these!

> > 
> > This version is different from the initial powervr driver submission [1]
> > in that it splits out the GPU glue layer support out of the powervr
> > driver and into a separate clock and power domain driver. The glue code
> > is otherwise the same, and also the same as found in the ChromeOS
> > kernels, with some extra comments and macro names added where possible.
> > 
> > Patch 1 adds a binding for the glue layer, called mfgtop. The glue layer
> > contains clock and power controls for the GPU.
> > 
> > Patch 2 adds a driver for the glue layer.
> > 
> > Patch 3 adds an entry for the MT8173 GPU and 6XT series to the PowerVR
> > binding.
> > 
> > Patch 4 adds an entry for the PowerVR 6XT series GPU to the driver.
> > 
> > Patch 5 corrects the clock for the GPU (called MFG) power domain.
> > 
> > Patch 6 adds device nodes for the GPU and glue layer to the MT8173 dtsi
> > file.
> > 
> > Patch 2 and 6 depend on patch 1 to build. I suppose some common
> > immutable tree would be needed from the MediaTek maintainers.
> > 
> > The kernel driver successfully probes the hardware and loads the
> > "rogue_4.40.2.51_v1.fw" firmware provided by Imagination Technologies [2].
> > Userspace was tested with Mesa 24.0.8 from Debian Trixie rebuilt with
> > the powervr vulkan driver enabled. `vulkaninfo` gives some information
> > about the GPU (attached at the end), but running the `triangle` example
> > from the Sascha Willems demos [3] with -DUSE_D2D_WSI=ON as recommended [4]
> > failed with:
> > 
> > Can't find a display and a display mode!
> > 
> > Same program worked correctly on a BeaglePlay and displayed a color
> > gradient triangle. Not sure what went wrong here.
> 
> Frank mentioned over IRC that giving `triangle` a screen resolution would
> make it work, and it did! Thanks Frank!

No problem :)

I've not dug into the display mode issue, but I'm wondering if it happens
because there isn't a mode flagged as the preferred mode.

> 
> OTOH I'm getting some extra warnings not seen on the BeaglePlay:
> 
> MESA: error: No hard coded passthrough rta vertex shader.
> Returning empty shader.
> MESA: warning: ../src/imagination/vulkan/pvr_job_context.c:71:
> FINISHME: Missing reset support for brn51764
> MESA: warning: ../src/imagination/vulkan/pvr_job_context.c:74:
> FINISHME: Missing reset support for brn58839
> MESA: warning: ../src/imagination/vulkan/pvr_border.c:104:
> FINISHME: Devices without tpu_border_colour_enhanced require entries
> for compressed formats to be stored in the table pre-compressed.
> 
> I also get a constant stream of kernel error messages, all the same:
> 
> powervr 1300.gpu: [drm] Received unknown FWCCB command 2abc0069
> 
> And the first few frames seem to flicker. (Though that could also be the
> display driver that's at fault.)

The unknown commands are related to the GPU locking up, presumably because bad
jobs are being submitted, likely due to missing bits of support for the
Series6XT GPUs in the Vulkan driver / compiler. The unknown commands are the
firmware notifying the host that the GPU has been reset. The GPU resets would
explain the flickering you're seeing.

Thanks
Frank

> 
> 
> For reference, on the BeaglePlay I see:
> 
> MESA: error: No hard coded idfwdf program. Returning empty program.
> MESA: error: No hard coded passthrough vertex shader. Returning
> empty shader.
> MESA: warning:
> ../src/imagination/vulkan/pvr_descriptor_set.c:1073: FINISHME: Entry
> tracker for allocations?
> 
> 
> Regards
> ChenYu
> 
> 
> > Anyway, please have a look and test.
> > 
> > 
> > Thanks
> > ChenYu
> > 
> > [1] 
> > https://lore.kernel.org/dri-devel/20220815165156.118212-2-sarah.wal...@imgtec.com/
> > [2] https://gitlab.freedesktop.org/imagination/linux-firmware/-/tree/powervr
> > [3] https://github.com/SaschaWillems/Vulkan
> > [4] 
> > https://lore.kernel.org/dri-devel/f2b2671e-5acc-4dec-9c2e-3c9cd2e1f...@imgtec.com/
> > 
> > Chen-Yu Tsai (6):
> >   dt-bindings: clock: mediatek: Add mt8173 mfgtop
> >   clk: mediatek: Add mt8173-mfgtop driver
> >   dt-bindings: gpu: powervr-rogue: Add MediaTek MT8173 GPU
> >   drm/imagination: Add compatible string entry for Series6XT
> >

Re: [ccp4bb] Crystal optimization

[Frank Von Delft]

Usually, you should try to push up the protein concentration, often quite a lot 
(30, 50, even 100 mg/ml), and decrease precipitant (might have to be really 
low, eg <3% PEG is not unthinkable).

To get the protein up, you may need to find a new buffer solution - there are 
screens for this, and DSF is one way to test. But might need a new construct or 
surface mutation or other protein engineering.

Good luck
Frank

Sent from tiny silly touch screen


From: 白雪慧 
Sent: Friday, 31 May 2024 03:33
To: CCP4BB@JISCMAIL.AC.UK
Subject: [ccp4bb] Crystal optimization

Thank you very much for your suggestions. I have a question. My crystal grows 
microcrystals under multiple conditions, as shown in the figure. After 
orthogonal optimization of the precipitant and pH, the crystal growth is still 
very small and difficult to obtain diffraction. What is the method to optimize 
and increase the crystal size in this situation?




To unsubscribe from the CCP4BB list, click the following link:
https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=CCP4BB=1



To unsubscribe from the CCP4BB list, click the following link:
https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=CCP4BB=1

This message was issued to members of www.jiscmail.ac.uk/CCP4BB, a mailing list 
hosted by www.jiscmail.ac.uk, terms & conditions are available at 
https://www.jiscmail.ac.uk/policyandsecurity/

[ia64] Results for 15.0.0 20240528 (experimental) [master revision 236116068151bbc72aaaf53d0f223fe06f7e3bac] (GCC) testsuite on ia64-t2-linux-gnu

[Frank Scheiner via Gcc-testresults]

in
/dev/shm/gcc-15/src.gcc.ia64-toolchain-3.240529.112623.549077/gcc/gcc.build.lnx/gcc



date; time make -j4 check-gcc 2>&1; echo $?; date
Thu May 30 09:43:20 UTC 2024

=== gcc tests ===

Running target unix
FAIL: gcc.c-torture/compile/attr-retain-1.c   -O0   scan-assembler
.rodata.*,"aR"
FAIL: gcc.c-torture/compile/attr-retain-1.c   -O1   scan-assembler
.bss.*,"awR"
FAIL: gcc.c-torture/compile/attr-retain-1.c   -O1   scan-assembler
.rodata.*,"aR"
FAIL: gcc.c-torture/compile/attr-retain-1.c   -O2   scan-assembler
.bss.*,"awR"
FAIL: gcc.c-torture/compile/attr-retain-1.c   -O2   scan-assembler
.rodata.*,"aR"
FAIL: gcc.c-torture/compile/attr-retain-1.c   -O3 -g   scan-assembler
.bss.*,"awR"
FAIL: gcc.c-torture/compile/attr-retain-1.c   -O3 -g   scan-assembler
.rodata.*,"aR"
FAIL: gcc.c-torture/compile/attr-retain-1.c   -Os   scan-assembler
.bss.*,"awR"
FAIL: gcc.c-torture/compile/attr-retain-1.c   -Os   scan-assembler
.rodata.*,"aR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -O0   scan-assembler
.bss.used_bss,"awR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -O0   scan-assembler
.bss.used_bss2,"awR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -O0   scan-assembler
.data.used_data,"awR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -O0   scan-assembler
.data.used_data2,"awR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -O0   scan-assembler
.rodata.used_rodata,"aR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -O0   scan-assembler
.rodata.used_rodata2,"aR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -O1   scan-assembler
.bss.used_bss,"awR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -O1   scan-assembler
.bss.used_bss2,"awR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -O1   scan-assembler
.data.used_data,"awR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -O1   scan-assembler
.data.used_data2,"awR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -O1   scan-assembler
.rodata.used_rodata,"aR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -O1   scan-assembler
.rodata.used_rodata2,"aR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -O2   scan-assembler
.bss.used_bss,"awR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -O2   scan-assembler
.bss.used_bss2,"awR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -O2   scan-assembler
.data.used_data,"awR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -O2   scan-assembler
.data.used_data2,"awR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -O2   scan-assembler
.rodata.used_rodata,"aR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -O2   scan-assembler
.rodata.used_rodata2,"aR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -O3 -g   scan-assembler
.bss.used_bss,"awR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -O3 -g   scan-assembler
.bss.used_bss2,"awR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -O3 -g   scan-assembler
.data.used_data,"awR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -O3 -g   scan-assembler
.data.used_data2,"awR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -O3 -g   scan-assembler
.rodata.used_rodata,"aR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -O3 -g   scan-assembler
.rodata.used_rodata2,"aR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -Os   scan-assembler
.bss.used_bss,"awR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -Os   scan-assembler
.bss.used_bss2,"awR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -Os   scan-assembler
.data.used_data,"awR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -Os   scan-assembler
.data.used_data2,"awR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -Os   scan-assembler
.rodata.used_rodata,"aR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -Os   scan-assembler
.rodata.used_rodata2,"aR"
FAIL: gcc.c-torture/compile/pr29201.c   -O0  (test for excess errors)
FAIL: gcc.c-torture/compile/pr29201.c   -O1  (test for excess errors)
FAIL: gcc.c-torture/compile/pr29201.c   -O2  (test for excess errors)
FAIL: gcc.c-torture/compile/pr29201.c   -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions  (test for
excess errors)
FAIL: gcc.c-torture/compile/pr29201.c   -O3 -g  (test for excess errors)
FAIL: gcc.c-torture/compile/pr29201.c   -Os  (test for excess errors)
WARNING: program timed out
FAIL: gcc.c-torture/compile/limits-blockid.c   -O3 -g  (test for excess
errors)
FAIL: gcc.c-torture/execute/pr64242.c   -O0  execution test
FAIL: gcc.c-torture/execute/pr64242.c   -O1  execution test
FAIL: gcc.c-torture/execute/pr64242.c   -O2  execution test
FAIL: gcc.c-torture/execute/pr64242.c   -O3 -g  execution test
FAIL: gcc.c-torture/execute/pr64242.c   -Os  execution test
FAIL: gcc.c-torture/execute/pr84521.c   -O0  execution test
FAIL: gcc.c-torture/execute/pr84521.c   -O1  execution test
FAIL: gcc.c-torture/execute/pr84521.c   -O2  execution test
FAIL: gcc.c-torture/execute/pr84521.c   -O3 -g  execution test
FAIL: gcc.c-torture/execute/pr84521.c   -Os  execution test
FAIL: gcc.dg/atomic/c11-atomic-exec-5.c   -O0  execution test
FAIL: gcc.dg/atomic/c11-atomic-exec-5.c   

[users] Re: Linux distribution

[Frank Bendon via Users]

Hi Martin
Thanks for the reply.  I went through the "ChirpOnLinux" procedure but 
just get pages full of complaints about missing modules despite pip 
saying they were already installed - at least all the ones I tried.  The 
version in the debian repository hangs when trying to download from a 
radio, it is probably quite old.   I would prefer a static binary - it 
would be more reliable.


Cheers
Frank
VK5BF

On 30/5/24 12:42 am, Martin Cooper via Users wrote:

Hi Frank,

Assuming you are following the instructions here (linked from the Downloads
page):

https://chirpmyradio.com/projects/chirp/wiki/ChirpOnLinux

what "failed dependencies" are you seeing?

Martin.
KD6YAM

On Wed, May 29, 2024 at 6:32 AM Frank via Users <
users@lists.chirpmyradio.com> wrote:


Is there an appImage (compiled) version of Chirp available?  - for the
various versions of linux.Both the .whl and tar.gz versions currently
on the chirp website do not work (failed dependencies)
___
Users mailing list
users@lists.chirpmyradio.com
https://lists.chirpmyradio.com/postorius/lists/users.lists.chirpmyradio.com
To unsubscribe, send an email to users-le...@lists.chirpmyradio.com
To report this email as off-topic, please email
users-ow...@lists.chirpmyradio.com
List archives:
https://lists.chirpmyradio.com/hyperkitty/list/users@lists.chirpmyradio.com/


___
Users mailing list
users@lists.chirpmyradio.com
https://lists.chirpmyradio.com/postorius/lists/users.lists.chirpmyradio.com
To unsubscribe, send an email to users-le...@lists.chirpmyradio.com
To report this email as off-topic, please email 
users-ow...@lists.chirpmyradio.com
List archives: 
https://lists.chirpmyradio.com/hyperkitty/list/users@lists.chirpmyradio.com/

___
Users mailing list
users@lists.chirpmyradio.com
https://lists.chirpmyradio.com/postorius/lists/users.lists.chirpmyradio.com
To unsubscribe, send an email to users-le...@lists.chirpmyradio.com
To report this email as off-topic, please email 
users-ow...@lists.chirpmyradio.com
List archives: 
https://lists.chirpmyradio.com/hyperkitty/list/users@lists.chirpmyradio.com/

Re: [petsc-users] Question on MatMatmult

[Frank Bramkamp]

Ah ok,

Then I will have a look at matconvert. 
And then maybe later switch to AIJ as well.


Thanks of the help, Frank


> On 29 May 2024, at 16:57, Barry Smith  wrote:
> 
> 
>   You can use MatConvert()
> 
> 
>> On May 29, 2024, at 10:53 AM, Frank Bramkamp  wrote:
>> 
>> This Message Is From an External Sender
>> This message came from outside your organization.
>> Hello Hong,
>> 
>> Thank you for the clarification.
>> If I already have a BAIJ matrix format, can I then convert it later into AIJ 
>> format as well ?!
>> In that case I would have two matrices, but that would be ok for testing.
>> I think that you sometimes convert different matrix formats into each other 
>> ?!
>> 
>> 
>> Since I typically have BAIJ format, I also use a blocked ILU, which would 
>> turn into a point wise ILU
>> for an AIJ matrix. That is why I typically have the BAIJ format.
>> 
>> Otherwise, I have to change it into an AIJ format from the beginning.
>> 
>> 
>> Thanks for the quick help,
>> 
>> Frank
>> 
>> 
>> 
>> 
> 

[Bug 2067355] Re: Update s390-tools to (currently latest) v2.33.1 in oracular

[Frank Heimes]

Test build is available in PPA lp2067355:
https://launchpad.net/~fheimes/+archive/ubuntu/lp2067355

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2067355

Title:
  Update s390-tools to (currently latest) v2.33.1 in oracular

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/2067355/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 2067355] Re: Update s390-tools to (currently latest) v2.33.1 in oracular

[Frank Heimes]

** Patch added: 
"debdiff_s390-tools-signed_from_2.31.0-0ubuntu5_to_2.33.1-0ubuntu1.diff"
   
https://bugs.launchpad.net/ubuntu/+source/s390-tools/+bug/2067355/+attachment/5784042/+files/debdiff_s390-tools-signed_from_2.31.0-0ubuntu5_to_2.33.1-0ubuntu1.diff

** Changed in: s390-tools (Ubuntu)
   Status: New => In Progress

** Changed in: s390-tools-signed (Ubuntu)
   Status: New => In Progress

** Changed in: ubuntu-z-systems
   Status: New => In Progress

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2067355

Title:
  Update s390-tools to (currently latest) v2.33.1 in oracular

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/2067355/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 2067355] Re: Update s390-tools to (currently latest) v2.33.1 in oracular

[Frank Heimes]

** Attachment added: 
"debdiff_s390-tools_from_2.31.0-0ubuntu5_to_2.33.1-0ubuntu1.diff.gz"
   
https://bugs.launchpad.net/ubuntu/+source/s390-tools/+bug/2067355/+attachment/5784041/+files/debdiff_s390-tools_from_2.31.0-0ubuntu5_to_2.33.1-0ubuntu1.diff.gz

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2067355

Title:
  Update s390-tools to (currently latest) v2.33.1 in oracular

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/2067355/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[med-svn] [Git][med-team/simrisc][pristine-tar] pristine-tar data for simrisc_16.00.00.orig.tar.gz

[Frank B. Brokken (@fbb-guest)]

Frank B. Brokken pushed to branch pristine-tar at Debian Med / simrisc


Commits:
9bf6dc96 by Frank B. Brokken at 2024-05-29T17:41:34+02:00
pristine-tar data for simrisc_16.00.00.orig.tar.gz

- - - - -


2 changed files:

- + simrisc_16.00.00.orig.tar.gz.delta
- + simrisc_16.00.00.orig.tar.gz.id


Changes:

=
simrisc_16.00.00.orig.tar.gz.delta
=
Binary files /dev/null and b/simrisc_16.00.00.orig.tar.gz.delta differ


=
simrisc_16.00.00.orig.tar.gz.id
=
@@ -0,0 +1 @@
+704ee9ab59ca3a12386e0e2e91ef6ffce2fa983e



View it on GitLab: 
https://salsa.debian.org/med-team/simrisc/-/commit/9bf6dc966dbf140a3fe4d09b21e1ef549fac787f

-- 
This project does not include diff previews in email notifications.
View it on GitLab: 
https://salsa.debian.org/med-team/simrisc/-/commit/9bf6dc966dbf140a3fe4d09b21e1ef549fac787f
You're receiving this email because of your account on salsa.debian.org.


___
debian-med-commit mailing list
debian-med-com...@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-commit

[med-svn] [Git][med-team/simrisc][debian/latest] 3 commits: Ready for simrisc 16.00.00-1

[Frank B. Brokken (@fbb-guest)]

Frank B. Brokken pushed to branch debian/latest at Debian Med / simrisc


Commits:
20e07b55 by Frank B. Brokken at 2024-05-29T17:41:27+02:00
Ready for simrisc 16.00.00-1

- - - - -
ce15ad23 by Frank B. Brokken at 2024-05-29T17:41:30+02:00
New upstream version 16.00.00
- - - - -
fc672b3b by Frank B. Brokken at 2024-05-29T17:41:34+02:00
Update upstream source from tag upstream/16.00.00

Update to upstream version 16.00.00
with Debian dir a805862182d9cdc6c2b6ba6934ea00daeb167350
- - - - -


30 changed files:

- CLASSES
- INSTALL.im
- VERSION
- agegroupvsd/agegroupvsd.h
- agegroupvsd/agegroupvsd.ih
- agegroupvsd/agegroupvsd1.cc
- agegroupvsd/insert1.cc
- + agegroupvsd/ln.cc
- analysis/run.cc
- beir7/beir71.cc
- beir7/writeparameters.cc
- changelog
- costs/costs1.cc
- costs/setage.cc
- costs/setdiameters.cc
- costs/setdiscount.cc
- costs/setproportion.cc
- costs/setvariables.cc
- costs/writeparameters.cc
- ct/setsensitivity.cc
- debian/changelog
- debian/control
- debian/rules
- debian/tests/run-unit-test
- debian/tests/simrisc-test1.expected.gz
- debian/tests/simrisc-test2.expected.gz
- densities/writeparameters.cc
- distribution/distribution.h
- distribution/distribution1.cc
- distribution/insert.cc


The diff was not included because it is too large.


View it on GitLab: 
https://salsa.debian.org/med-team/simrisc/-/compare/3120f000de49aa9bec406559a34bcf5c31510526...fc672b3b4e3721838b788bd33d9964abac16acb4

-- 
This project does not include diff previews in email notifications.
View it on GitLab: 
https://salsa.debian.org/med-team/simrisc/-/compare/3120f000de49aa9bec406559a34bcf5c31510526...fc672b3b4e3721838b788bd33d9964abac16acb4
You're receiving this email because of your account on salsa.debian.org.


___
debian-med-commit mailing list
debian-med-com...@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-commit

[med-svn] [Git][med-team/simrisc][upstream] New upstream version 16.00.00

[Frank B. Brokken (@fbb-guest)]

Frank B. Brokken pushed to branch upstream at Debian Med / simrisc


Commits:
ce15ad23 by Frank B. Brokken at 2024-05-29T17:41:30+02:00
New upstream version 16.00.00
- - - - -


30 changed files:

- CLASSES
- INSTALL.im
- VERSION
- agegroupvsd/agegroupvsd.h
- agegroupvsd/agegroupvsd.ih
- agegroupvsd/agegroupvsd1.cc
- agegroupvsd/insert1.cc
- + agegroupvsd/ln.cc
- analysis/run.cc
- beir7/beir71.cc
- beir7/writeparameters.cc
- changelog
- costs/costs1.cc
- costs/setage.cc
- costs/setdiameters.cc
- costs/setdiscount.cc
- costs/setproportion.cc
- costs/setvariables.cc
- costs/writeparameters.cc
- ct/setsensitivity.cc
- densities/writeparameters.cc
- distribution/distribution.h
- distribution/distribution1.cc
- distribution/insert.cc
- + distribution/ln.cc
- documentation/man/simrisc.yo
- documentation/man/simriscparams.yo
- documentation/manual/simrisc.yo
- dot.config/simrisc
- enums/enums.h


The diff was not included because it is too large.


View it on GitLab: 
https://salsa.debian.org/med-team/simrisc/-/commit/ce15ad233b892e931d3bf1b403aac0e2dadab7df

-- 
This project does not include diff previews in email notifications.
View it on GitLab: 
https://salsa.debian.org/med-team/simrisc/-/commit/ce15ad233b892e931d3bf1b403aac0e2dadab7df
You're receiving this email because of your account on salsa.debian.org.


___
debian-med-commit mailing list
debian-med-com...@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-commit

[slurm-users] dynamical configuration || meta configuration mgmt

[Heckes, Frank via slurm-users]

Hello all, 

I’m sorry if this has been asked and answered before, but I couldn’t find 
anything related.

 

Does anyone know whether a framework of sorts exists that allow to change 
certain SLURM configuration parameters provided some conditions in the batch 
system’s state are detected and of course are revert if the state became the 
old one again?

(To be more concrete: We like to raise or unset maxjobPU to run as much  small 
jobs as possible to allocate all nodes as soon as certain threshold of free 
nodes are available and of course some other scenarios)

Many thanks in advance.

Cheers,

-Frank

 

Max-Planck-Institut

für Sonnensystemforschung

Justus-von-Liebig-Weg 3

D-37077 Göttingen

Phone: [+49] 551 – 384 979 320

E-Mail:  <mailto:hec...@mps.mpg.de> hec...@mps.mpg.de

 



smime.p7s
Description: S/MIME cryptographic signature

-- 
slurm-users mailing list -- slurm-users@lists.schedmd.com
To unsubscribe send an email to slurm-users-le...@lists.schedmd.com

Re: [petsc-users] Question on MatMatmult

[Frank Bramkamp]

 Hello Hong, Thank you for the clarification. If I already have a BAIJ matrix format, can I then convert it later into AIJ format as well ?! In that case I would have two matrices, but that would be ok for testing. I think that you sometimes




ZjQcmQRYFpfptBannerStart




  

  
	This Message Is From an External Sender
  
  
This message came from outside your organization.
  



 
  


ZjQcmQRYFpfptBannerEnd




Hello Hong,

Thank you for the clarification.
If I already have a BAIJ matrix format, can I then convert it later into AIJ format as well ?!
In that case I would have two matrices, but that would be ok for testing.
I think that you sometimes convert different matrix formats into each other ?!


Since I typically have BAIJ format, I also use a blocked ILU, which would turn into a point wise ILU
for an AIJ matrix. That is why I typically have the BAIJ format.

Otherwise, I have to change it into an AIJ format from the beginning.


Thanks for the quick help,

Frank