Skip to content

Commit 95808c5

Browse files
Jacopo Mondipelwell
authored andcommitted
media: pisp_be: Remove config validation from schedule()
The config parameters buffer is already validated in pisp_be_validate_config() at .buf_prepare() time. However some of the same validations are also performed at pispbe_schedule() time. In particular the function checks that: 1) config.num_tiles is valid 2) At least one of the BAYER or RGB input is enabled The input config validation is already performed in pisp_be_validate_config() and while job.hw_enables is modified by pispbe_xlate_addrs(), the function only resets the input masks if - there is no input buffer available, but pispbe_prepare_job() fails before calling pispbe_xlate_addrs() in this case - bayer_enable is 0, but in this case rgb_enable is valid as guaranteed by pisp_be_validate_config() - only outputs are reset in rgb_enable For this reasons there is no need to repeat the check at pispbe_schedule() time. The num_tiles validation can be moved to pisp_be_validate_config() as well. As num_tiles is a u32 it can'be be < 0, so change the sanity check accordingly. Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Naushir Patuck <naush@raspberrypi.com> Signed-off-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
1 parent 69ddd18 commit 95808c5

File tree

1 file changed

+7
-19
lines changed
  • drivers/media/platform/raspberrypi/pisp_be

1 file changed

+7
-19
lines changed

drivers/media/platform/raspberrypi/pisp_be/pisp_be.c

Lines changed: 7 additions & 19 deletions
Original file line numberDiff line numberDiff line change
@@ -621,25 +621,6 @@ static void pispbe_schedule(struct pispbe_dev *pispbe,
621621
pispbe->hw_busy = true;
622622
spin_unlock_irqrestore(&pispbe->hw_lock, flags);
623623

624-
if (job.config->num_tiles <= 0 ||
625-
job.config->num_tiles > PISP_BACK_END_NUM_TILES ||
626-
!((job.hw_enables.bayer_enables |
627-
job.hw_enables.rgb_enables) &
628-
PISP_BE_BAYER_ENABLE_INPUT)) {
629-
/*
630-
* Bad job. We can't let it proceed as it could lock up
631-
* the hardware, or worse!
632-
*
633-
* For now, just force num_tiles to 0, which causes the
634-
* H/W to do something bizarre but survivable. It
635-
* increments (started,done) counters by more than 1,
636-
* but we seem to survive...
637-
*/
638-
dev_dbg(pispbe->dev, "Bad job: invalid number of tiles: %u\n",
639-
job.config->num_tiles);
640-
job.config->num_tiles = 0;
641-
}
642-
643624
pispbe_queue_job(pispbe, &job);
644625

645626
return;
@@ -738,6 +719,13 @@ static int pisp_be_validate_config(struct pispbe_node_group *node_group,
738719
return -EIO;
739720
}
740721

722+
if (config->num_tiles == 0 ||
723+
config->num_tiles > PISP_BACK_END_NUM_TILES) {
724+
dev_dbg(dev, "%s: Invalid number of tiles: %d\n", __func__,
725+
config->num_tiles);
726+
return -EINVAL;
727+
}
728+
741729
/* Ensure output config strides and buffer sizes match the V4L2 formats. */
742730
fmt = &node_group->node[TDN_OUTPUT_NODE].format;
743731
if (bayer_enables & PISP_BE_BAYER_ENABLE_TDN_OUTPUT) {

0 commit comments

Comments
 (0)