The Scrum Guide defines it as a timebox, meaning the outside time is the maximum time to spend. That being said, if you're going to just continue sprint planning without calling it that anyway, you're just hiding the disfunction. I would be inclined to make what seems like the best call in the moment and then reflect as a team about why it occurred.
For example, if it's taking long because the team is new and they are learning about how to run Sprint Planning while they are doing it, then the problem will resolve itself. On the other hand, if you have a bunch of items ready to work, you may decide to just start with what you have.
It's important to keep in mind that the structure given in the Scrum Guide should help alleviate this problem.
Topic One of planning is what can be done in the sprint from the product backlog. This is where the PO sets their preferred direction and the team weighs in on what items seem reasonable. After this topic, you have a proposed Sprint Backlog and Sprint Goal. This can be enough to go on, though it'll be rocky.
Topic Two is for the team to put together a preliminary plan on how to do the work, starting with the backlog items at the top of the list.
Note that Topic One doesn't include planning or tasking out work. It's just selection. This keeps deep dive discussions one one or two items from dragging out and keeping sprint planning from effectively getting done in the timebox. When you move on to Topic Two, you get as far as you get. The first things to be worked on are the first to be talked about, so wherever you get to is fine to start the sprint.
